Systems and methods for providing fraud indicator data within an authentication protocol

ABSTRACT

A computing device for risk-based analysis of a payment card transaction is provided herein. The computing device includes a processor communicatively coupled to a memory. The computing device is programmed to receive a request for authentication of the payment card transaction. The payment card transaction includes a suspect consumer presenting a payment card from a digital wallet of a privileged cardholder. The computing device is also programmed to identify fraud feature data from the digital wallet. The computing device is further programmed to compute a fraud score for the payment card transaction based at least in part on the fraud feature data. The computing device is still further programmed to provide the fraud score for use during authentication of the suspect consumer.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationSer. No. 62/051,150, filed Sep. 16, 2014, which is incorporated hereinby reference in its entirety.

BACKGROUND OF THE DISCLOSURE

This invention relates generally to risk and fraud associated withpayment card transactions and, more particularly, to network-basedsystems and methods for providing risk analysis and decision-makingservices for a merchant while processing payment card transactions.

At least some known credit/debit card purchases involve fraudulentactivity. These fraudulent transactions present liability issues to oneor more parties involved in the transaction, such as an issuing bank, amerchant, a payment processing network, or an acquirer bank. As such,these parties are interested in fraud detection, or the ability toanalyze the data surrounding a payment card transaction beforeauthorizing the transaction. Accordingly, a technical solution isdesirable that provides a risk-based evaluation and a decisioningservice to one or more of the parties during a payment card transaction.

BRIEF DESCRIPTION OF THE DISCLOSURE

In one aspect, a computing device for risk-based analysis of a paymentcard transaction is provided. The computing device includes a processorcommunicatively coupled to a memory. The computing device is programmedto receive a request for authentication of the payment card transaction.The payment card transaction includes a suspect consumer presenting apayment card from a digital wallet of a privileged cardholder. Thecomputing device is also programmed to identify fraud feature data fromthe digital wallet. The computing device is further programmed tocompute a fraud score for the payment card transaction based at least inpart on the fraud feature data. The computing device is still furtherprogrammed to provide the fraud score for use during authentication ofthe suspect consumer.

In another aspect, a computer-based method for risk-based analysis of apayment card transaction is provided. The method is implemented using acomputer device including a processor and a memory. The method includesreceiving a request for authentication of the payment card transaction.The payment card transaction includes a suspect consumer presenting apayment card from a digital wallet of a privileged cardholder. Themethod further includes identifying fraud feature data from the digitalwallet. The method also includes computing a fraud score for the paymentcard transaction based at least in part on the fraud feature data. Themethod still further includes providing the fraud score for use duringauthentication of the suspect consumer.

In yet another aspect, at least one non-transitory computer-readablestorage media having computer-executable instructions embodied thereonis provided. When executed by at least one processor, thecomputer-executable instructions cause the processor to receive arequest for authentication of a payment card transaction. The paymentcard transaction includes a suspect consumer presenting a payment cardfrom a digital wallet of a privileged cardholder. Thecomputer-executable instructions further cause the processor to identifyfraud feature data from the digital wallet. The computer-executableinstructions also cause the processor to compute a fraud score for thepayment card transaction based at least in part on the fraud featuredata. The computer-executable instructions still further cause theprocessor to provide the fraud score for use during authentication ofthe suspect consumer.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1-14 show example embodiments of the methods and systems describedherein.

FIG. 1 is a schematic diagram illustrating an example multi-partytransaction card industry system for authorizing payment cardtransactions and, more specifically, for providing fraud scoringservices for card-not-present transactions during user authenticationand/or payment authorization of a payment-by-card transaction (e.g.,online transactions involving a digital wallet).

FIG. 2 is a simplified block diagram of an example transactionprocessing system (TPS) for providing risk-based decisioning servicesusing a risk-based decisioning (RBD) system to merchants and/or merchantacquirers in payment network.

FIG. 3 is an expanded block diagram of an example embodiment of a serverarchitecture of a transaction processing network including a TPS, an RBDsystem, and an authentication service, that may be used to performvarious authentication services for a payment card transaction.

FIG. 4 illustrates an example configuration of a user system operated bya user such as the cardholder shown in FIG. 1.

FIG. 5 illustrates an example configuration of a server system such asthe server system shown in FIGS. 2 and 3.

FIG. 6 is a diagram of an example digital wallet of a cardholder.

FIG. 7 is a data flow diagram of an example risk-based decisioning (RBD)module which generates a risk result (“risk score”) for a transactioninvolving a digital wallet such as digital wallet.

FIG. 8 is a process diagram of an example process for computing riskresult for a digital-wallet based payment card transaction such as thetransaction shown in FIG. 7.

FIG. 9 is a diagram of an example payment network in which a transactionprocessing system (TPS) facilitates risk-based decisioning of acard-not-present (CNP) payment card transaction (the “suspecttransaction” or “subject transaction”) between a suspect consumer and amerchant.

FIG. 10 is swimlane diagram illustrating an exemplary portion of anauthentication request process that includes providing authenticationdata to an issuer during transaction authentication.

FIG. 11 is an example method for risk-based analysis of a payment cardtransaction using, for example, the risk-based decisioning (RBD) systemshown in FIGS. 7-9 in the example environment shown in FIG. 1.

FIG. 12 is an example method for providing risk-based decisioning to amerchant during payment card transactions in the example environmentshown in FIG. 1.

FIG. 13 is an example method for providing fraud data within anauthentication system including an authentication protocol.

FIG. 14 shows an example configuration of a database within a computingdevice, along with other related computing components, that may be usedto analyze of a payment card transaction for risk, to provide risk-baseddecisioning to a merchant during payment card transactions, and/or toprovide fraud data within an authentication system including anauthentication protocol.

Like numbers in the Figures indicate the same or functionally similarcomponents.

DETAILED DESCRIPTION OF THE DISCLOSURE

Systems and methods are described herein for evaluating payment cardtransactions for fraud. In one aspect, systems and methods are providedfor performing risk-based decisioning for payment card transactionsinvolving a digital wallet and associated data. In another aspect,systems and methods are provided for providing risk-based decisioning tomerchants and/or merchant acquirers. In still another aspect, systemsand methods are provided for sharing risk-based decisioning data with anissuer through use of extensions to an authentication protocol.

Risk-based decisioning for payment card transactions involves evaluatingdata included within a prior authorization message of a payment cardtransaction. At least some known credit/debit card purchases involve theexchange of a number of payment card network messages between themerchant, acquirer, and issuer parties of a four-party interchangemodel. Such messages may include authorizations, advices, reversals,account status inquiry presentments, purchase returns, and chargebacks.The credit or debit card payment transaction messages may includeseveral transaction attributes, such as, for example, primary accountnumber (either real or virtual), transaction amount, merchantidentifier, acquirer identifier (the combination of which with aboveuniquely identifies a merchant), transaction date-time, and addressverification.

In some situations such as in-store credit card purchases, the issuer ofthe credit card typically assumes liability for certain aspects of thetransaction, such as chargebacks. In other situations, such as onlinetransactions through a merchant web site, the merchant party in thetransaction assumes initial liability for certain aspects of thetransaction unless, for example, certain risk-mitigating steps aretaken, such as an authentication step. For example, some known paymentnetworks engage an authentication service such as a 3-D Secure® (VisaInternational Service Association, Delaware) (3DS) protocol (e.g.,MasterCard SecureCode® (MasterCard International Incorporated, Purchase,N.Y.)) that performs an authentication of a suspect consumer prior toauthorization of the transaction. During some known 3-D Securetransactions, the suspect consumer (i.e., the consumer attempting toperform the payment card transaction with the merchant) is presentedwith an authentication challenge, sometimes called a “step-upchallenge.” This step-up challenge generally requires the suspectconsumer to provide a password, or a passcode from a second factor userdevice, before the transaction will be processed. This extra steppresents an interruptive inconvenience, barrier, or an interference toat least some legitimate consumers, and subsequently causes at leastsome consumers to abandon legitimate transactions. These abandonmentsresults in lost revenues to both the merchant and the issuer.

One risk-based decisioning (RBD) system described herein evaluatespayment card transactions involving digital wallets. During a paymentcard transaction, such as an online transaction on a merchant web site,the suspect consumer uses a computing device such as a smart phone orpersonal computer device to login to a digital wallet. The suspectconsumer selects a payment card from the digital wallet for use in thetransaction, and the merchant or digital wallet provider initiates anauthentication process (i.e., to gauge whether or not the suspectconsumer is a privileged cardholder associated with the payment card).

The RBD system identifies one or more pieces of information about thepayment card transaction that are used to “score” the transaction forrisk (e.g., potential fraud). More specifically, the RBD system scoresthe payment card transaction based on three aspects: device information,payment card information, and digital wallet information. Deviceinformation may include information about the computing device usedduring the transaction, such as a unique hardware identifier, or an IPaddress associated with the device. Payment card information may includeinformation about the payment card or the privileged cardholder, such asan expiration date of the payment card or a name or a home address ofthe privileged cardholder. Digital wallet information may includeinformation about the digital wallet used during the transaction, suchas how the suspect consumer was authenticated into the digital wallet,whether the digital wallet has historically been used with the currentcomputing device, or whether the shipping address of the currenttransaction is a shipping address previously used with the digitalwallet.

In one embodiment, the RBD system generates a device score from thedevice information and a digital wallet score from the digital walletinformation and combines these scores into a session trust level. Thesession trust level generally indicates a confidence as to whether ornot the user of the device and wallet is the privileged cardholder. Thislevel may be a level such as, for example, one of “basic”, “good”,“excellent”, and “trusted.” The RBD system also generates a payment cardscore from the payment card information and combines the payment cardscore with the session trust level to generate an overall transactionrisk level for the payment card transaction. From this overalltransaction risk level, the RBD system generates a baselinerecommendation.

In some embodiments, parties to the transaction (e.g., issuers) mayprovide to the RBD system certain transaction limits, such as atransaction amount limit for individual payment cards, a daily spendlimit, or a number of transactions limit. Further, these limits may becustomized based at least in part on the overall transaction risk level.For example, transactions that the RBD system scores as less risky(e.g., “excellent” or “trusted” overall risk level) may have higherthresholds (e.g., higher transaction amount limit) than transactionsthat the RBD system scores as more risky.

In some embodiments, the RBD system may be provided as a service toissuing banks. In other words, the RBD system may provide scores to anissuer's access control system (ACS), and the ACS may make decisionsbased at least in part on the risk scores or risk data available fromthe RBD system.

In another aspect described herein, the RBD system sends risk-baseddecisioning data to the issuer's ACS via an extension message to the 3DSprotocol. For example, the RBD system may score the payment cardtransaction and provide an overall score and/or an overallrecommendation to the issuer's ACS by embedding an XML-formatted messageas a 3DS extension during the authentication process. The RBD system maysend other “sub-scores” within the 3DS extension message, such as thedevice score, the digital wallet score, or the payment card score. Insome embodiments, the RBD system may share individual risk-based dataelements such as the method the suspect consumer authenticated into thedigital wallet, or how long the digital wallet has been in service.Using this risk-based data, the issuer's ACS determines whether or notthe suspect consumer should be further authenticated (e.g., through a3DS “step-up” challenge).

In yet another aspect described herein, the RBD system is presented foruse by a merchant, a merchant acquirer, and/or a merchant serviceprovider in card-not-present (CNP) transactions, such as onlinetransactions. One risk-mitigating step for some issuers and largemerchants is to perform their own risk-based decisioning on thetransaction prior to authorization, such as described above. Theseparties may establish a custom fraud analysis system to analyzetransactions for fraud. However, these systems can be resource-intensiveand, as such, not feasible for smaller entities, such as small- ormedium-sized merchants.

In an example embodiment, a transaction processing system (TPS) providesmerchants and/or acquiring banks an option to perform risk-baseddecisioning on payment card transactions prior to the normalauthorization process. For certain types of transactions, merchants mayretain liability for the transaction. As such, merchants may desireadditional risk mitigation by analyzing transactions for potential fraudprior to accepting liability. In one embodiment, an acquiring bank mayoffer or provide this risk-based decisioning process to one or more oftheir associated merchants, and thus may engage the TPS of the paymentnetwork to perform this process for those merchant transactions. Inother words, the payment network provides this service on behalf of theacquiring banks to the merchants. In another embodiment, merchants maydirectly engage the payment network to perform this process on behalf ofthe merchant. In yet another embodiment, a third-party processingservice performs this process on behalf of the merchant.

One TPS described herein engages an RBD system on behalf of themerchant, or the acquiring bank, during a payment card transaction. Morespecifically, at the time a transaction is initiated, the TPS receivestransaction data from the merchant and/or merchant acquirer. The TPS mayalso identify additional data associated with the subject transaction,such as, for example, one or more of (1) information about a computingdevice used to conduct the subject transaction (“device information”,e.g., geo-location data of the device Internet protocol (IP) address),(2) additional payment card information not included in the transactiondata (“payment card information”), (3) information about a digitalwallet used to conduct the subject transaction (“digital walletinformation”, e.g., whether and/or how often this particular device hasbeen used in conjunction with this digital wallet), and (4) cart dataassociated with the subject transaction (“cart data”). This additionaldata may also be individually or collectively referred to asinfrastructure data, because it refers to the infrastructure used by theTPS to process a transaction, and/or as fraud feature data because, asdescribed below, at least some of this data may be used as part of afraud- or risk-scoring process.

The TPS transmits the transaction data and infrastructure data to theRBD system for scoring. The RBD system is configured to score theriskiness of the subject transaction and determine whether or notadditional authentication should be initiated. More specifically, theRBD system scores the subject transaction based at least in part on thetransaction data and the infrastructure data. If the score is below thepre-defined threshold (i.e., “less risky”), then the transaction will beapproved at this stage and subsequently will continue through toauthorization without additional authentication of the suspect consumer.If the score is above a pre-defined threshold (i.e., “more risky”), thenthe transaction will undergo additional, direct authentication of thesuspect consumer (e.g., a 3DS “step-up” challenge). In the former case,the merchant may maintain liability for the subject transaction, butunder the knowledge that the RBD system has analyzed the transaction forfraud prior to completion. In the latter case, the suspect consumer ischallenged during the transaction, thus providing additionalauthentication of the suspect consumer in those situations where thetransaction seems most risky.

At least one of the technical problems addressed by this systemincludes: (i) high network load based at least in part on step-upchallenging most or all card-not-present transactions which results innetwork delays and reduced bandwidth; (ii) allowing fraudulenttransactions to be successfully processed if there is no step-upchallenge of a card-not-present transaction; (iii) consumerinconvenience during card-not-present transactions based at least inpart on having to answer an additional authentication challenge during atransaction; (iv) abandonment of transactions by consumers when facedwith a step-up challenge, thus leading to lost sales for merchants andlost processing fees for the other network parties based on thoseabandoned transactions; (v) unavailability of customizable fraud-relatedservices to merchants and/or merchant acquirers; (vi) increased riskwith merchant liability for fraudulent transactions; (vii) digitalwallet-related fraud; (viii) issuers having limited access to some datathat may be used to fraud-score transactions.

A technical effect of the systems and processes described herein isachieved by performing at least one of the following steps: (i)receiving a request for authentication of the payment card transaction,the payment card transaction including a suspect consumer presenting apayment card from a digital wallet of a privileged cardholder; (ii)identifying fraud feature data from the digital wallet; (iii) computinga fraud score for the payment card transaction based at least in part onthe fraud feature data; and (iv) providing the fraud score for useduring authentication of the suspect consumer.

The technical effect achieved by this system is at least one of: (i)reducing the amount of network and computing resources needed to reducethe number of fraudulent transactions processed by the payment network;(ii) reducing the number of fraudulent transactions being processed;(iii) reducing consumer inconvenience during card-not-presenttransactions; (iv) reducing the number of transactions that areabandoned by consumers when faced with an additional authenticationchallenge, and thus reducing lost sales for the merchant and reducinglost fees for the other network parties based on those abandonedtransactions; (v) enabling liability shift to issuing banks for sometransactions; (vi) providing additional fraud-related data to issuersduring authentication and/or authorization of transactions; (vii)including digital wallet-related data in fraud scoring of transactions;(vii) providing a risk-based decisioning service to issuers thatincludes digital wallet-related data; (viii) providing a risk-baseddecisioning service to merchants and/or merchant acquirers when issuersare not participating; (ix) enabling merchants and/or issuers tocustomize how their transactions are risk-scored and authenticated. Forexample, network resources and computing resources are reduced byreducing the number of step-up challenges being performed, and thus thenumber of messages transmitted and processed across the network. Insteadof requiring a step-up challenge on each and every card-not-presenttransaction, the present system intelligently determines whichtransactions require the step-up challenge and which do not. One or moreof the parties to the transaction are benefitted by the system by, forexample, less burden on the consumer to further authenticate themselvesduring the transaction, and fewer abandoned transactions for themerchant (e.g., lost sales), and for the acquiring bank, network, andissuer (e.g., lost transaction processing fees).

As used herein, the term “authentication” (or an “authenticationprocess”) is used generally to refer to a process conducted on a paymenttransaction prior to the “authorization” of a transaction (or an“authorization process”). At least one purpose of the authenticationprocess is to evaluate whether or not the person conducting thetransaction (the “suspect consumer”) is actually a person privileged touse the payment card presented in the transaction (the “privilegedcardholder”). For example, issuers may want to authenticate an onlinetransaction to evaluate whether or not the user of a computing deviceconducting the online transaction is really the privileged cardholder.An authentication process may be used to reduce fraudulent transactions,and thus protect one or more parties to the transaction (e.g., themerchant, or the issuer of the subject payment card).

As used herein, a processor may include any programmable systemincluding systems using micro-controllers, reduced instruction setcircuits (RISC), application specific integrated circuits (ASICs), logiccircuits, and any other circuit or processor capable of executing thefunctions described herein. The above examples are example only, and arethus not intended to limit in any way the definition and/or meaning ofthe term “processor.”

As used herein, the terms “software” and “firmware” are interchangeable,and include any computer program stored in memory for execution by aprocessor, including RAM memory, ROM memory, EPROM memory, EEPROMmemory, and non-volatile RAM (NVRAM) memory. The above memory types areexample only, and are thus not limiting as to the types of memory usablefor storage of a computer program.

In one embodiment, a computer program is provided, and the program isembodied on a computer readable medium. In an example embodiment, thesystem is executed on a single computer system, without requiring aconnection to a sever computer. In a further embodiment, the system isbeing run in a Windows® environment (Windows is a registered trademarkof Microsoft Corporation, Redmond, Wash.). In yet another embodiment,the system is run on a mainframe environment and a UNIX® serverenvironment (UNIX is a registered trademark of X/Open Company Limitedlocated in Reading, Berkshire, United Kingdom). The application isflexible and designed to run in various different environments withoutcompromising any major functionality. In some embodiments, the systemincludes multiple components distributed among a plurality of computingdevices. One or more components may be in the form ofcomputer-executable instructions embodied in a computer-readable medium.The systems and processes are not limited to the specific embodimentsdescribed herein. In addition, components of each system and eachprocess can be practiced independent and separate from other componentsand processes described herein. Each component and process can also beused in combination with other assembly packages and processes.

As used herein, the terms “transaction card,” “financial transactioncard,” and “payment card” refer to any suitable transaction card, suchas a credit card, a debit card, a prepaid card, a charge card, amembership card, a promotional card, a frequent flyer card, anidentification card, a prepaid card, a gift card, and/or any otherdevice that may hold payment account information, such as mobile phones,Smartphones, personal digital assistants (PDAs), key fobs, digitalwallets, and/or computers. Each type of transactions card can be used asa method of payment for performing a transaction. As used herein, theterm “payment account” is used generally to refer to the underlyingaccount with the transaction card. In addition, cardholder card accountbehavior can include but is not limited to purchases, managementactivities (e.g., balance checking), bill payments, achievement oftargets (meeting account balance goals, paying bills on time), and/orproduct registrations (e.g., mobile application downloads).

The following detailed description illustrates embodiments of thedisclosure by way of example and not by way of limitation. It iscontemplated that the disclosure has general application to processingfinancial transaction data by a third party in industrial, commercial,and residential applications.

As used herein, an element or step recited in the singular and proceededwith the word “a” or “an” should be understood as not excluding pluralelements or steps, unless such exclusion is explicitly recited.Furthermore, references to “example embodiment” or “one embodiment” ofthe present disclosure are not intended to be interpreted as excludingthe existence of additional embodiments that also incorporate therecited features.

FIG. 1 is a schematic diagram illustrating an example multi-partytransaction card industry system 20 for authorizing payment cardtransactions and, more specifically, for providing fraud scoringservices for card-not-present transactions during user authenticationand/or payment authorization of a payment-by-card transaction (e.g.,online transactions involving a digital wallet). Embodiments describedherein may relate to a transaction card system, such as a credit cardpayment system using the MasterCard® interchange network. TheMasterCard® interchange network is a set of proprietary communicationsstandards promulgated by MasterCard International Incorporated® for theexchange of financial transaction data and the settlement of fundsbetween financial institutions that are members of MasterCardInternational Incorporated®. (MasterCard is a registered trademark ofMasterCard International Incorporated located in Purchase, N.Y.).

In a typical transaction card system, a financial institution called the“issuer” issues a transaction card, such as a credit card, to a consumeror cardholder 22, who uses the transaction card to tender payment for apurchase from a merchant 24. To accept payment with the transactioncard, merchant 24 must normally establish an account with a financialinstitution that is part of the financial payment system. This financialinstitution is usually called the “merchant bank,” the “acquiring bank,”or the “acquirer.” When cardholder 22 tenders payment for a purchasewith a transaction card, merchant 24 requests authorization from amerchant bank 26 for the amount of the purchase. The request may beperformed over the telephone, but is usually performed through the useof a point-of-sale terminal, which reads cardholder's 22 accountinformation from a magnetic stripe, a chip, or embossed characters onthe transaction card and communicates electronically with thetransaction processing computers of merchant bank 26. Alternatively,merchant bank 26 may authorize a third party to perform transactionprocessing on its behalf. In this case, the point-of-sale terminal willbe configured to communicate with the third party. Such a third party isusually called a “merchant processor,” an “acquiring processor,” or a“third party processor.”

Using an interchange network 28, computers of merchant bank 26 ormerchant processor will communicate with computers of an issuer bank 30to determine whether cardholder's 22 account 32 is in good standing andwhether the purchase is covered by cardholder's 22 available creditline. Based on these determinations, the request for authorization willbe declined or accepted. If the request is accepted, an authorizationcode is issued to merchant 24.

When a request for authorization is accepted, the available credit lineof cardholder's 22 account 32 is decreased. Normally, a charge for apayment card transaction is not posted immediately to cardholder's 22account 32 because bankcard associations, such as MasterCardInternational Incorporated®, have promulgated rules that do not allowmerchant 24 to charge, or “capture,” a transaction until goods areshipped or services are delivered. However, with respect to at leastsome debit card transactions, a charge may be posted at the time of thetransaction. When merchant 24 ships or delivers the goods or services,merchant 24 captures the transaction by, for example, appropriate dataentry procedures on the point-of-sale terminal. This may includebundling of approved transactions daily for standard retail purchases.If cardholder 22 cancels a transaction before it is captured, a “void”is generated. If cardholder 22 returns goods after the transaction hasbeen captured, a “credit” is generated. Interchange network 28 and/orissuer bank 30 stores the transaction card information, such as a typeof merchant, amount of purchase, date of purchase, in a database 120(shown in FIG. 2).

After a purchase has been made, a clearing process occurs to transferadditional transaction data related to the purchase among the parties tothe transaction, such as merchant bank 26, interchange network 28, andissuer bank 30. More specifically, during and/or after the clearingprocess, additional data, such as a time of purchase, a merchant name, atype of merchant, purchase information, cardholder account information,a type of transaction, savings information, itinerary information,information regarding the purchased item and/or service, and/or othersuitable information, is associated with a transaction and transmittedbetween parties to the transaction as transaction data, and may bestored by any of the parties to the transaction.

After a transaction is authorized and cleared, the transaction issettled among merchant 24, merchant bank 26, and issuer bank 30.Settlement refers to the transfer of financial data or funds amongmerchant's 24 account, merchant bank 26, and issuer bank 30 related tothe transaction. Usually, transactions are captured and accumulated intoa “batch,” which is settled as a group. More specifically, a transactionis typically settled between issuer bank 30 and interchange network 28,and then between interchange network 28 and merchant bank 26, and thenbetween merchant bank 26 and merchant 24.

In some embodiments, the payment card transaction is a card-not-presenttransaction conducted, for example, with a payment card in a digitalwallet. Network 28 includes a risk-based decisioning (RBD) module (notseparately shown in FIG. 1) that is configured to analyze various dataassociated with the payment card transaction and provide variousservices to one or more parties involved in the payment cardtransaction, such as merchant 24 and issuer 30. In one embodiment,during an authentication process for the payment card transaction, theRBD module generates a risk score for the payment card transaction usingpayment card data, device information, and digital wallet informationused during the transaction. In another embodiment, the RBD modulegenerates and transmits extension messages to an issuer in a 3DSprotocol for use by the issuer to determine, using their own risk-baseddecisioning system, whether or not to prompt the cardholder for afurther verification (e.g., issue a step-up challenge). The messagesinclude elements of data from one or more of the payment card data, thedevice information data, and the digital wallet information. In yetanother embodiment, the RBD module scores the payment card transactionon behalf of the merchant and provides notification to the merchantregarding transaction risk.

FIG. 2 is a simplified block diagram of an example transactionprocessing system (TPS) 101 for providing risk-based decisioningservices using an RBD system 121 to merchants and/or merchant acquirersin payment network 100. In some embodiments, network 100 is similar topayment network 20 (shown in FIG. 1). In the example embodiment, network100 includes a plurality of computer devices connected in communicationin accordance with the present disclosure. Network 100 includes a serversystem 112 of TPS 101 in communication with a point-of-sale (POS)terminal 118 at a merchant location 24 (shown in FIG. 1), and/or otherclient systems 114 associated with merchants, merchant banks, paymentnetworks, and/or issuer banks.

More specifically, in the example embodiment, TPS 101 includes a serversystem 112 of, for example, a payment processing network 28, incommunication with a point-of-sale (POS) terminal 118 at a merchantlocation 24, and/or other client systems 114 associated with merchants,merchant banks, payment networks, and/or issuer banks. Server system 112is also in communication with a plurality of client sub-systems, alsoreferred to as client systems 114. In one embodiment, client systems 114are computers including a web browser, such that server system 112 isaccessible to client systems 114 using the Internet. Client systems 114are interconnected to the Internet through many interfaces including anetwork 115, such as a local area network (LAN) or a wide area network(WAN), dial-in-connections, cable modems, special high-speed IntegratedServices Digital Network (ISDN) lines, and RDT networks. Client systems114 could be any device capable of interconnecting to the Internetincluding a web-based phone, PDA, or other web-based connectableequipment.

In the example embodiment, TPS 101 also includes POS terminals 118,which may be connected to client systems 114 and may be connected toserver system 112. POS terminals 118 may be interconnected to theInternet (or any other network that allows the POS terminals 118 tocommunicate as described herein) through many interfaces including anetwork, such as a local area network (LAN) or a wide area network(WAN), dial-in-connections, cable modems, wireless modems, and specialhigh-speed ISDN lines. POS terminals 118 could be any device capable ofinterconnecting to the Internet and including an input device capable ofreading information from a cardholder's financial transaction card. Insome embodiments, POS terminal 118 may be a cardholder's personalcomputer, such as when conducting an online purchase through theInternet. As used herein, the terms POS device, POS terminal, and pointof interaction device are used broadly, generally, and interchangeablyto refer to any device in which a cardholder interacts with a merchantto complete a payment card transaction.

A database server 116 is connected to database 120, which containsinformation on a variety of matters, as described below in greaterdetail. In one embodiment, centralized database 120 is stored on serversystem 112 and can be accessed by potential users at one of clientsystems 114 by logging onto server system 112 through one of clientsystems 114. In an alternative embodiment, database 120 is storedremotely from server system 112 and may be non-centralized.

Database 120 may include a single database having separated sections orpartitions or may include multiple databases, each being separate fromeach other. Database 120 may store transaction data generated as part ofsales activities and savings activities conducted over the processingnetwork including data relating to merchants, account holders orcustomers, issuers, acquirers, savings amounts, savings accountinformation, and/or purchases made. Database 120 may also store accountdata including at least one of a cardholder name, a cardholder address,an account number, and other account identifier. Database 120 may alsostore merchant data including a merchant identifier that identifies eachmerchant registered to use the network, and instructions for settlingtransactions including merchant bank account information. Database 120may also store purchase data associated with items being purchased by acardholder from a merchant, and authorization request data. Database 120may also store digital wallet information, device information, paymentcard information, scoring rules, risk thresholds, and other datainvolved with providing risk-based decisioning to one or more parties tothe transaction.

In the example embodiment, one of client systems 114 may be associatedwith acquirer bank 26 (shown in FIG. 1) while another one of clientsystems 114 may be associated with issuer bank 30 (shown in FIG. 1). POSterminal 118 may be associated with a participating merchant 24 (shownin FIG. 1) or may be a computer system and/or mobile system used by acardholder making an on-line purchase or payment. Server system 112 maybe associated with interchange network 28 or a payment processor. In theexample embodiment, server system 112 is associated with a networkinterchange, such as interchange network 28, and may be referred to asan interchange computer system or a payment processing computing device.Server system 112 may be used for processing transaction data. Inaddition, client systems 114 and/or POS terminal 118 may include acomputer system associated with at least one of an online bank, a billpayment outsourcer, an acquirer bank, an acquirer processor, an issuerbank associated with a transaction card, an issuer processor, a remotepayment system, a token requestor, a token provider, and/or a biller.

In some embodiments, TPS 101 is in communication with RBD system 121 andan authentication service 123. In some embodiments, RBD system 121and/or authentication service 123 are third-party systems. In otherembodiments, one or more of RBD system 121 and/or authentication service123 may be a part of TPS 101. In some embodiments, RBD system 121 and/orauthentication service 123 are in communication with each other and maydirectly interact during the processing of payment card transactions. Inthe example embodiment, RBD system 121 performs fraud scoring on paymentcard transactions, and authentication service 123 provides additionalauthentication services for suspect consumers during the payment cardtransaction if RBD system 121 generates a score above a pre-definedthreshold (i.e., indicating that the transaction is of greater risk froma fraud perspective). In some embodiments, RBD system 121 and/orauthentication service 122 are also in communication with a merchantsystem and/or an issuer system (e.g., computer 114) and/or POS terminal118 of the merchant.

FIG. 3 is an expanded block diagram of an example embodiment of a serverarchitecture of a transaction processing network 122 including atransaction processing system (TPS) 101, an RBD system 121, and anauthentication service 123, that may be used to perform variousauthentication services for a payment card transaction. Components insystem 122, identical to components of system 100 (shown in FIG. 2), areidentified in FIG. 3 using the same reference numerals as used in FIG.2. Transaction processing system 122 includes server system 112, clientsystems 114, and POS terminals 118. Server system 112 further includesdatabase server 116, a transaction server 124, a web server 126, a faxserver 128, a directory server 130, and a mail server 132. A storagedevice 134 is coupled to database server 116 and directory server 130.Servers 116, 124, 126, 128, 130, and 132 are coupled in a local areanetwork (LAN) 136. In addition, an issuer bank workstation 138, anacquirer bank workstation 140, and a third party processor workstation142 may be coupled to LAN 136. In the example embodiment, issuer bankworkstation 138, acquirer bank workstation 140, and third partyprocessor workstation 142 are coupled to LAN 136 using networkconnection 115. Workstations 138, 140, and 142 are coupled to LAN 136using an Internet link or are connected through an Intranet.

Each workstation 138, 140, and 142 is a personal computer having a webbrowser. Although the functions performed at the workstations typicallyare illustrated as being performed at respective workstations 138, 140,and 142, such functions can be performed at one of many personalcomputers coupled to LAN 136. Workstations 138, 140, and 142 areillustrated as being associated with separate functions only tofacilitate an understanding of the different types of functions that canbe performed by individuals having access to LAN 136.

Server system 112 is configured to be communicatively coupled to variousindividuals, including employees 144 and to third parties, e.g., accountholders, customers, auditors, developers, cardholders (i.e., consumers),merchants, acquirers, issuers, etc., 146 using an ISP Internetconnection 148. The communication in the example embodiment isillustrated as being performed using the Internet, however, any otherwide area network (WAN) type communication can be utilized in otherembodiments, i.e., the systems and processes are not limited to beingpracticed using the Internet. In addition, and rather than WAN 150,local area network 136 could be used in place of WAN 150.

In the example embodiment, any authorized individual having aworkstation 154 can access system 122. At least one of the clientsystems includes a manager workstation 156 located at a remote location.Workstations 154 and 156 are personal computers having a web browser.Also, workstations 154 and 156 are configured to communicate with serversystem 112. Furthermore, fax server 128 communicates with remotelylocated client systems, including a client system 156 using a telephonelink. Fax server 128 is configured to communicate with other clientsystems 138, 140, and 142 as well.

FIG. 4 illustrates an example configuration of a user system 202operated by a user 201, such as cardholder 22 (shown in FIG. 1). In someembodiments, user system 202 is a merchant system and/or a merchant POSdevice. In the example embodiment, user system 202 includes a processor205 for executing instructions. In some embodiments, executableinstructions are stored in a memory area 210. Processor 205 may includeone or more processing units, for example, a multi-core configuration.Memory area 210 is any device allowing information such as executableinstructions and/or written works to be stored and retrieved. Memoryarea 210 may include one or more computer readable media.

User system 202 also includes at least one media output component 215for presenting information to user 201. Media output component 215 isany component capable of conveying information to user 201. In someembodiments, media output component 215 includes an output adapter suchas a video adapter and/or an audio adapter. An output adapter isoperatively coupled to processor 205 and operatively couplable to anoutput device such as a display device, a liquid crystal display (LCD),organic light emitting diode (OLED) display, or “electronic ink”display, or an audio output device, a speaker or headphones.

In some embodiments, user system 202 includes an input device 220 forreceiving input from user 201. Input device 220 may include, forexample, a keyboard, a pointing device, a mouse, a stylus, a touchsensitive panel, a touch pad, a touch screen, a gyroscope, anaccelerometer, a position detector, or an audio input device. A singlecomponent such as a touch screen may function as both an output deviceof media output component 215 and input device 220. User system 202 mayalso include a communication interface 225, which is communicativelycouplable to a remote device such as server system 112. Communicationinterface 225 may include, for example, a wired or wireless networkadapter or a wireless data transceiver for use with a mobile phonenetwork, Global System for Mobile communications (GSM), 3G, or othermobile data network or Worldwide Interoperability for Microwave Access(WIMAX).

Stored in memory area 210 are, for example, computer readableinstructions for providing a user interface to user 201 via media outputcomponent 215 and, optionally, receiving and processing input from inputdevice 220. A user interface may include, among other possibilities, aweb browser and client application. Web browsers enable users, such asuser 201, to display and interact with media and other informationtypically embedded on a web page or a web site from server system 112. Aclient application allows user 201 to interact with a server applicationfrom server system 112.

In the example embodiment, computing device 202 is a user computingdevice from which user 201 engages with a digital wallet (not shown inFIG. 3), an online merchant (e.g., merchant 24, shown in FIG. 1), anetwork (e.g., network 28, shown in FIG. 1), and an issuer of a paymentcard (e.g., issuer 30, shown in FIG. 1) to perform a transaction whichundergoes a user authentication process.

FIG. 5 illustrates an example configuration of a server system 301 suchas server system 112 (shown in FIGS. 2 and 3). Server system 301 mayinclude, but is not limited to, database server 116, web server 126,application server 124, RBD system 121, TPS 101, and/or authenticationservice 123.

Server system 301 includes a processor 305 for executing instructions.Instructions may be stored in a memory area 310, for example. Processor305 may include one or more processing units (e.g., in a multi-coreconfiguration) for executing instructions. The instructions may beexecuted within a variety of different operating systems on the serversystem 301, such as UNIX, LINUX, Microsoft Windows®, etc. It should alsobe appreciated that upon initiation of a computer-based method, variousinstructions may be executed during initialization. Some operations maybe required in order to perform one or more processes described herein,while other operations may be more general and/or specific to aparticular programming language (e.g., C, C#, C++, Java, or othersuitable programming languages, etc.).

Processor 305 is operatively coupled to a communication interface 315such that server system 301 is capable of communicating with a remotedevice such as user system 202 (shown in FIG. 4) or another serversystem 301. For example, communication interface 315 may receiverequests from user system 114 via the Internet, as illustrated in FIGS.2 and 3.

Processor 305 may also be operatively coupled to a storage device 134.Storage device 134 is any computer-operated hardware suitable forstoring and/or retrieving data. In some embodiments, storage device 134is integrated in server system 301. For example, server system 301 mayinclude one or more hard disk drives as storage device 134. In otherembodiments, storage device 134 is external to server system 301 and maybe accessed by a plurality of server systems 301. For example, storagedevice 134 may include multiple storage units such as hard disks orsolid state disks in a redundant array of inexpensive disks (RAID)configuration. Storage device 134 may include a storage area network(SAN) and/or a network attached storage (NAS) system.

In some embodiments, processor 305 is operatively coupled to storagedevice 134 via a storage interface 320. Storage interface 320 is anycomponent capable of providing processor 305 with access to storagedevice 134. Storage interface 320 may include, for example, an AdvancedTechnology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, aSmall Computer System Interface (SCSI) adapter, a RAID controller, a SANadapter, a network adapter, and/or any component providing processor 305with access to storage device 134.

Memory area 310 may include, but are not limited to, random accessmemory (RAM) such as dynamic RAM (DRAM) or static RAM (SRAM), read-onlymemory (ROM), erasable programmable read-only memory (EPROM),electrically erasable programmable read-only memory (EEPROM), andnon-volatile RAM (NVRAM). The above memory types are exemplary only, andare thus not limiting as to the types of memory usable for storage of acomputer program.

In the example embodiment, server system 301 is a risk-based decisioning(RBD) system in communication with one or more of issuer 30 and merchant24 during a payment card transaction involving a digital wallet of auser. RBD system 301 performs risk analysis of the payment cardtransaction and provides one or more authentication-related servicesduring the transaction.

FIG. 6 is a diagram of an example digital wallet 600 of a cardholder602. During a payment card transaction, a suspect consumer (not shown)presents a payment card 620 from digital wallet 600 to a merchant (e.g.,merchant 24, shown in FIG. 1) to purchase goods or services. Arisk-based decisioning (RBD) module (not shown in FIG. 6) uses variousdata about digital wallet 600 to perform one or more authenticationservices associated with the payment card transaction. In other words,the RBD module will help determine whether or not the suspect consumer(i.e., the person using digital wallet 600 during this transaction) isthe privileged cardholder (e.g., cardholder 602, “A. Smith”).

In the example embodiment, digital wallet 600 includes devices data 610,payment cards data 620, loyalty cards data 630, and personal data 640.Digital wallet 600 may also include access method data, biometric data,and behavioral information. Some or all of this data may be stored in acentralized database (e.g., database 120, shown in FIG. 2), on a user'sdevice (e.g., device 612), at network 28, merchant 24, and/or issuer 30(all shown in FIG. 1). This data may also be individually orcollectively referred to as infrastructure data, because it refers tothe infrastructure used by the TPS to process a transaction, and/or asfraud feature data because, as described below, at least some of thisdata may be used as part of a fraud- or risk-scoring process.

Device data 610 includes data about devices somehow associated withdigital wallet 600. Device data 610 may include data associated with oneor more devices 612, 614, 616 that have historically been used duringpast payment card transactions. Further, device data 610 may includedata about a device currently being used for a present payment cardtransaction. For example, devices data 610 may include an InternetProtocol (IP) address, a media access control (MAC) address, or otheridentifier that may be used to identify particular devices 612, 614,618. In some embodiments, device data 610 may include a fraudulentdevice status (e.g., whether the device has been involved in pastfraudulent transactions).

Digital wallet 600, in the example embodiment, also includes paymentcards data 620 for one or more payment cards 622. During the life of adigital wallet, cardholder 602 may enter one or more payment cards 622into digital wallet 600 for use in payment card transactions. Paymentcards data 620 may include, for example, payment card authorizationnumbers (PANs), expiration dates, issuing bank names, associatedsecurity codes (e.g., a CVC2 code), cardholder name, tokens representingor otherwise associated with payment cards, and other data associatedwith payment cards 622.

In some embodiments, payment cards data 620 includes which payment cards622 were used with which devices 612. Further, in some embodiments,payment cards data 620 includes an age of payment card 622 withindigital wallet 600. In other words, digital wallet 600 tracks how longeach payment card 622 has been loaded into digital wallet 600. Further,in some embodiments, payment cards data 620 includes a history of cardauthentications for payment cards 622. For example, one payment card mayhave been successfully or unsuccessfully 3DS-authenticated, orsecure-code authenticated, several times in the past. For example, if apayment card is used from digital wallet 600 for a past legitimatetransaction (e.g., one not associated with a chargeback) then,controlling for all other variables, a subsequent transaction with thatpayment card/digital wallet may be scored in such a way indicating thatthe subsequent transaction is less risky from a fraud perspective.Similarly, if there are fraudulent transactions and/or transactions thatresult in a chargeback, then the subsequent transaction with thatpayment card/digital wallet may be scored in such a way indicating thatthe subsequent transaction is riskier from a fraud perspective. Suchdata may be tied to a particular payment card, a particular digitalwallet, and/or a particular device.

In some embodiments, payment cards data 620 includes data indicating howpayment cards 622 were loaded into digital wallet 600 (e.g., manuallyentered by a user, loaded by the issuing bank or the digital walletprovider). In some embodiments, payment cards data 620 includes statusdata for payment cards 622 (e.g., whether a card is “blacklisted”, has aprior history of fraudulent transactions, has a clean prior history). Insome embodiments, payment cards data 620 includes transaction amountlimits, daily spending limits, weekly spending limits, and/or a numberof transactions limit associated with payment card 622. In someembodiments, payment cards data 620 includes the number of wallets intowhich a particular payment card 622 has been loaded, and/or a number ofmerchant sites into which the particular payment card has been loaded.

In some embodiments, device data 610 and/or payment card data 620 mayinclude a recognized secure element such as, for example, a tokenassociated with a particular device and/or payment card (e.g., as withMasterCard® Digital Enablement Service (MDES), or Digital Secure RemotePayments (DSRP)). In some embodiments, this secure element may beprovided by a piece of hardware such as a separate computing device thatis separated from the device being used in the payment card transaction.For example, during a prior payment card transaction involving digitalwallet 600, the secure element is generated and/or validated as a partof the transaction, and subsequently associated with digital wallet 600(e.g., as a part of device data 610 or payment card data 620). Thenduring a later transaction, a current secure element provided as a partof the transaction (e.g., by a mobile phone accessing digital wallet 600for the transaction) may be compared to the prior secure element indevice data 610 and/or payment card data 620. If the current secureelement is recognized as previously used, the current transaction may bescored “less risky” than the alternative. As such, this may also resultin an improved cardholder experience, as it may decrease the likelihoodof a step-up challenge to the cardholder.

In the example embodiment, digital wallet 600 also includes loyaltycards data 630 for one or more loyalty programs. Some merchants provideloyalty (“rewards”) programs for their regular customers, such as toincentivize more purchases by the accountholder (e.g., cardholder 302).Some digital wallets, including the example digital wallet 600, enablecardholders 602 to load loyalty cards 632 into the digital wallet (inaddition to payment cards 622). As such, loyalty cards data 630 includesdata such as an account number (i.e., unique identifier identifying thecardholder's account), a merchant name, and a cardholder name.

Digital wallet 600, in the example embodiment, also includes personaldata 640 associated with cardholder 602. Digital wallet 600 and/ormerchants 24 may store personal information that is regularly used inpayment card transactions so that, for example, cardholder 602 can moreeasily populate data into a payment card transaction rather than have toremember and/or manually enter such data. For example, personal data 640may include addresses 642 of cardholder 602, such as a home address anda work address, which may be regularly reused as mailing addresses fordigital wallet purchases.

In some embodiments, personal data 640 may also include (1) informationabout digital wallet 600 such as, for example, (a) an account age fordigital wallet 600 (e.g., how long digital wallet has been open and/oractive), and (b) a provider of digital wallet 600. In some embodiments,personal data 640 includes (2) one or more email addresses and/or phonenumbers associated with cardholder 602. In some embodiments, personaldata 640 may include (3) information associated with a plurality ofprivileged cardholders 602, such as spouses.

Additionally, in some embodiments, personal data 640 may includetransaction data associated with the present transaction, such as atransaction type of the present transaction. The transaction type mayinclude E-Commerce, mobile payment using QR code, mobile payment usingnear-field communication (NFC), mobile payment using Bluetooth lowenergy (BLE), and/or mobile payment using another technology. Further,the transaction type may also include an application programminginterface (API) designation used by the merchant. For example, somemerchants may use a particular checkout type that utilizes a risk-baseddecisioning system (e.g., as described below), while other merchants mayutilize data stored in the digital wallet, paired with the merchant, andthen requested by the merchant at the time of the transaction.

Further, in the example embodiment, cardholder 602 (or the suspectconsumer) accesses digital wallet 600 through one or more access methods650. At least some digital wallets provide multiple avenues of access,or methods of authenticating into the digital wallet. In someembodiments, cardholder 602 may authenticate into digital wallet 600through the wallet provider. For example, the wallet provider may be anissuing bank, and may provide a user name and password to cardholder602, and cardholder 602 may subsequently use that user name and passwordas an access method 650. In some embodiments, cardholder 602 mayauthenticate into digital wallet 600 through a merchant site (e.g.,using a merchant-provided account). For example, cardholder 602 may havea user name and password with a merchant's web site. During an onlineshopping experience, cardholder 602 may login to the merchant's website, select items for purchase, and select digital wallet 600 for usein completing payment. Digital wallet 600 may associate cardholder's 602merchant login account with cardholder 602 and, as such, may “trust” themerchant login authentication as a successful authentication (and accessmethod) into digital wallet 600. In some embodiments, the digital walletprovider may require an additional authentication into digital wallet600 using the digital wallet provider's authentication service prior to“trusting” the merchant login as authentication into digital wallet 600.In some embodiments, cardholder 602 may authenticate into digital wallet600 through a payment network such as network 28. For example, network28 may provide a user authentication mechanism for authenticatingcardholder 602 and, as such, cardholder 602 may be authenticated intodigital wallet 600 through this access method.

In some embodiments, digital wallet 600 also includes biometric dataassociated with cardholder 602, payment cards 622, loyalty cards 632,and/or devices 612. Such biometric data may include, for example,biometric reference samples such as cardholder's 602 registered(authentic) fingerprint or iris image that may be used to authenticate asuspect consumer during a payment card transaction. Further, in someembodiments, digital wallet 600 includes behavioral informationassociated with cardholder 602, digital wallet 600, devices 612, paymentcards 622, loyalty cards 632, and/or personal data 640. For example,digital wallet 600 may include past use data, behavioral information,transaction history, or other behavioral data for each of theseelements.

FIG. 7 is a data flow diagram 700 of an example risk-based decisioning(RBD) module 750 which generates a risk result 752 (“risk score”) for atransaction 710 involving a digital wallet such as digital wallet 600.In some embodiments, RBD module 750 is similar to RBD system 121 (shownin FIGS. 2 and 3). In the example embodiment, a suspect consumer 702engages in transaction 710 with merchant 24 using digital wallet 600.For example, suspect consumer 702 may use computing device 704 to loginto a website of merchant 24 and select digital wallet 600 for use incompleting transaction 710. More specifically, suspect consumer 702 mayselect a specific bank card 712 within digital wallet 600 to completetransaction 710. RBD module 750 is configured to determine if suspectconsumer 702 is the privileged user of digital wallet 600 and/or paymentcard 712 (e.g., cardholder 602).

In the example embodiment, RBD module 750 generates risk result 752based at least in part on one or more sources of information abouttransaction 710. RBD module 750 is configured to consider fraud featuredata such as device information 720, digital wallet information 730, andpayment card information 740 when evaluating risk associated withtransaction 710. In some embodiments, historical data 760 and scoringrules 770 may also be considered. Further, in some embodiments, riskresult 752 includes one or more of (1) a numerical risk value computedfor transaction 710 as a whole, and (2) a risk level indicator fortransaction 710 as a whole, (3) one or more risk level indicators and/ornumerical risk values for one or more of (a) a device score (e.g., fordevice 704), (b) a digital wallet score (e.g., for digital wallet 600),and (c) a payment card score (e.g., for payment card 712).

In some embodiments, some or all of device information 720 may bereceived from one or more sources such as, for example, a merchantsystem, an issuer system, a digital wallet provider system, a thirdparty device scoring system, and/or the suspect consumer's 702 device704. Additionally, in some embodiments, some or all of digital walletinformation 730 may be received by RBD module 750 from one or moresources such as, for example, a payment transaction processing systemsuch as described in reference to FIG. 10 and a third party system suchas a digital wallet provider system, and/or RBD module 750 may havedirect access to some or all of digital wallet information 730. Further,some or all of payment card information 740 may be received by RBDmodule 750 from a third party system such as a payment network system,the payment transaction processing system described in reference to FIG.10, a merchant system, and an issuer system, and/or RBD module 750 mayhave direct access to some or all of payment card information 740.

FIG. 8 is a process diagram of an example process 800 for computing riskresult 752 for a digital-wallet based payment card transaction such astransaction 710 (shown in FIG. 7). In the example embodiment, risk-baseddecisioning (RBD) module 750 performs process 800 on a computing devicesuch as server 112 (shown in FIG. 2) while in communication with network28. In some embodiments, RBD module 750 is in communication with one ormore additional computing systems such as a merchant system, an issuersystem, or one or more third-party systems.

In the example embodiment, RBD module 750 determines a device score atstep 810 using at least device information 720. The device scorerepresents one factor of risk-based evaluation, where the device scorefocuses on the computing device being used in the transaction (e.g.,computing device 704, shown in FIG. 7). In other words, the device scorerelates to how much more or less likely the transaction is to be risky(e.g., fraudulent) based on information about the suspect consumer'scomputing device (i.e., whether or not the device is trustworthy). Inthe example embodiment, the device score is a level determined from thetiered set of “Basic/Can't Tell”, “Good”, and “Excellent”. In someembodiments, RBD module 750 may communicate with a third party systemfor at least some device scoring. RBD module 750 may provide at leastsome device information 720, digital wallet information 730, and/orpayment card information 740 to the third party system.

RBD module 750, in the example embodiment, also determines an accessmethod score at step 820 using at least digital wallet information 730.The access method score represents a factor of risk-based evaluation,where the access method score focuses on data involving the digitalwallet being used in the transaction (e.g., digital wallet 600, shown inFIGS. 6 and 7). In other words, the access method score relates to howmuch more or less likely the transaction is to be risky (e.g.,fraudulent) based on information about the suspect consumer's digitalwallet (i.e., whether or not the use of the digital wallet, orparticular aspects of the digital wallet, is trustworthy).

In the example embodiment, the access method score is a level determinedfrom the tiered set of “None”, “Basic”, “Good”, “Excellent”, and“Trusted”. RBD module 750 determines an access method score based atleast in part on the access method that the suspect consumer used toauthenticate into the digital wallet in use during the subjecttransaction. Several different avenues of access, or access methods 650,are described above in reference to FIG. 6. RBD module 750 determinesthe particular access method used by suspect consumer 702 toauthenticate with digital wallet 600 during transaction 710 and assignsa particular level based at least in part on that access method. Forexample, if suspect consumer 702 authenticated by providing a biometricimage that was subsequently confirmed as authentic, then RBD module 750may assign an “Excellent” level to the access method score. For anotherexample, if suspect consumer 702 authenticated with a login name andpassword directly with the digital wallet provider, then RBD module 750may assign a “good” level to the access method score. This may be lower(i.e., considered “more risky” from a fraud perspective) than otherlevels because, for example, some login-based authentication methods maybe compromised more easily than some biometric authentication methods(e.g., stolen login names and passwords, easily guessed passwords). Foranother example, if suspect consumer 702 is cross-authenticated or“trusted” into the digital wallet based on a merchant login, then RBDmodule 750 may assign a “basic” level to the access method score. Thismay be lower (i.e., considered “more risky” from a fraud perspective)than other levels because, for example, some merchant sites may haveless rigorous standards for authentication into their site (e.g., laxpassword strength standards, indefinite account lifetimes, longerpassword expiration times).

In some embodiments, RBD module 750 includes one or more additionaldigital wallet-based risk factors when determining the access methodscore. For example, in one embodiment, RBD module 750 examineshistorical data 760 involving past authentication results involving oneor more of the subject payment card (e.g., payment card 712), thesubject digital wallet (e.g., digital wallet 600), and/or the subjectdevice (e.g., computing device 704) and alters the access method scorebased on this historical data. For example, RBD module 750 may adjustthe access method score to indicate an increased risk of fraud if thesubject payment card was used in a prior recent transaction in which anaddress verification system (AVS) check or a 3DS step-up was conductedbut failed. In some embodiments, RBD module 750 may adjust the accessmethod score based on how recent transactions with this payment cardwere authenticated. For example, a recent 3DS verification success mayindicate less risk for the current transaction than a recent AVS check,or than a non-verified transaction. As such, RBD module 750 may raise orlower the access method score based on such historical verificationdata. In some embodiments, RBD module 750 may examine how just the mostrecent transaction was authenticated, and the associated results.

In another embodiment, RBD module 750 examines past devices used duringtransactions involving the subject digital wallet. For example, if thesubject device (e.g., computing device 704) has been used several timesin past, non-fraudulent transactions, then it is more likely that thesubject transaction is non-fraudulent than if, for example, the subjectdevice has never been used with, or otherwise associated to, the subjectdigital wallet. As such, RBD module 750 may risk-score the subjecttransaction higher or lower based on perceived risk associated withprior-used devices.

In yet another embodiment, RBD module 750 examines how long the subjectdigital wallet has been in active service (e.g., how old account is),and/or the transaction volume associated with the subject digital wallet(e.g., how many total transactions have been completed, or how muchtotal has been spent), and/or how many times the user has authenticatedinto the subject digital wallet. For example, if the subject digitalwallet has been recently created and/or has a low volume oftransactions, then RBD module 750 may risk-score the subject transactionindicating an increased risk of fraud than if the digital wallet had along lifetime and/or a high volume of transactions.

In still another embodiment, RBD module 750 examines how long thesubject payment card (e.g., payment card 740) has been loaded into thesubject digital wallet, and/or how the subject payment card was loadedinto the wallet. For example, if the subject payment card was recentlyloaded into the digital wallet, and/or manually loaded into the wallet(e.g., by hand, by suspect consumer 702), then RBD module 750 mayrisk-score the subject transaction indicating an increased risk of fraudthan if the subject payment card was loaded into the wallet long ago,and/or loaded in by a more secure manner (e.g., by an issuer, or by thewallet provider).

In another embodiment, RBD module 750 examines how many cards are loadedinto the subject digital wallet, and/or information comparison betweenmultiple cards in the wallet. For example, if the subject digital walletincludes dozens of payment cards 622, and/or the payment cards sharediffering names or billing addresses, then RBD module 750 may risk-scorethe subject transaction indicating an increased risk of fraud than ifthe subject digital wallet only included a few payment cards, and/or thepayment cards within the wallet all shared similar names or billingaddresses.

In yet another embodiment, RBD module 750 compares a shipping address ofthe subject transaction to shipping addresses of past transactionsassociated with the digital wallet. If, for example, the subjectshipping address matches a shipping address previously used, and perhapsregularly used, then RBD module 750 may risk-score the subjecttransaction indicating a reduced risk of fraud than if the subjectshipping address were one never used in past digital wallet transactionsor otherwise not associated with the subject digital wallet.

Further, in some embodiments, RBD module 750 may combine one or more ofthe above digital-wallet-based behavioral items for risk-scoringpurposes. For example, RBD module 750 may examine how many times aparticular payment card has been used from a particular device withinthis digital wallet's history. RBD module 750 may risk-score the subjecttransaction lower risk if the subject payment card and the subjectdevice have been used together in numerous past transactions, or mayrisk-score the transaction higher risk if, for example, the subjectdevice had never been used with the subject payment card.

In some embodiments, the device score may be determined 810 using one ormore data elements from digital wallet information 730 and/or paymentcard information 770. Further, in some embodiments, the access methodscore may be determined 820 using one or more data elements from deviceinformation 720 and/or payment card information.

Referring now to FIG. 8, once a device score and an access method scorehave been determined, RBD module 750 combines the device score and theaccess method score to generate a session trust level at step 830. Inthe example embodiment, as described above, the device score may be oneof “Basic/Can't Tell”, “Good”, and “Excellent”, and the access methodscore may be one of “None”, “Basic”, “Good”, “Excellent”, and “Trusted”.RBD module 750 generates a session trust level that is one of “Basic”,“Good”, “Excellent”, and “Trusted.” More specifically, the followingtable indicates the resultant session trust level from the two variablesof device score (“Device”, vertical axis) and access method score(“Access”, horizontal axis):

TABLE 1 Session Trust Level Device Excellent Good Good ExcellentExcellent Trusted Good Basic Good Good Excellent Excellent Basic BasicBasic Good Good Excellent None Basic Good Excellent Trusted AccessMethodwhere the cross-referenced value (i.e., the value within the cell havingthe identified device score and access score) is the session trust levelfor the subject transaction.

In the example embodiment, RBD module 750 determines 840 a cardverification score using at least payment card information 740. In someembodiments, card verification score may be determined 840 using one ormore data elements from digital wallet information 730 and/or deviceinformation 720. The card verification score represents a factor ofrisk-based evaluation, where the card verification score focuses on thepayment card being used in the transaction (e.g., computing device 704,shown in FIG. 7). In other words, the device score relates to how muchmore or less likely the transaction is to be risky (e.g., fraudulent)based on information about the payment card being presented, accountdetails for the subject payment card, and accompanying transaction dataof the subject transaction. In the example embodiment, the cardverification score is a level determined from the tiered set of“Neutral/Can't Tell”, “Good”, “Excellent”, and “Trusted”. In someembodiments, RBD module 750 may communicate with another system for atleast some card verification scoring. The card verification score may bebased on factors such as, for example, address information provided bythe suspect consumer, how the payment card was loaded or added to thedigital wallet, and whether the subject payment card has been used withthe subject merchant.

Once RBD module 750 has a session trust level 830 and has determined 840a card verification score, RBD module 750 combines these two scores intoa transaction risk level 850. In the example embodiment, RBD module 750uses the following table to determine transaction risk level 850 fromthe two variables of session trust level 830 (“Session”, vertical axis)and the card verification score (“Card”, horizontal axis):

TABLE 2 Transaction Risk Level Session Trusted Basic Excellent TrustedTrusted Excellent Basic Good Excellent Trusted Good Basic Good GoodExcellent Basic Basic Basic Basic Basic Neutral Good Excellent TrustedCardwhere the cross-referenced value (i.e., the value within the cell havingthe identified session trust level 830 and the card verification score)is the overall transaction risk level for the subject transaction. Thus,transaction risk level 850 represents a combination of device score, adigital wallet/access method score, and a card verification score.

In the example embodiment, transaction risk level 850 represents abaseline recommendation 860 generated by RBD module 750. In other words,if no other considerations were included, RBD module 750 would providebaseline recommendation 860 as risk result 752. However, in the exampleembodiment, RBD module 750 additionally applies 870 one or moreoverrides and/or risk limits before generating a final risk result 752.In some embodiments, RBD module 750 may provide a default set of rulesthat are used to generate risk result 752. In the example embodiment,RBD module 750 enables issuer-specific risk limits. In other words, eachparticular issuing bank may provide its own custom set of rules to beapplied by RBD module 750 to generate risk result 752. For example, inone specific embodiment, an issuer customizes the following table ofrisk limits:

TABLE 3 Issuer Risk Limits Daily Weekly Transaction Transaction SpendingSpending # Transactions Risk Level Amount Limit Limit Limit LimitTrusted no limit no limit no limit no limit Excellent $1,000 $2,000$10,000 no limit Good $250 $1,000 $3,000 10 Neutral $100 $200 $500  5Negative all all all all

Each column of the table represents a particular aspect orcharacteristic associated with the transaction, the privilegedcardholder, or the payment card account (referred to herein as a“transaction aspects”). Each cell within the table may be configuredwith a threshold level, and each cell may also be associated with acorresponding transaction risk level (e.g., transaction risk level 850).Based on the determined transaction risk level 850, if one or more ofthe threshold levels is exceeded, RBD module 750 will recommend anadditional authentication of the suspect consumer (e.g., 3DS step-upauthentication). The threshold levels shown in Table 3 are merely oneexample. Issuers may elect to use any number of these or other limits atstep 870, or none at all.

In the example embodiment, for the subject payment card, RBD module 750determines a set of risk limits (e.g., table of risk limits) for thesubject transaction (e.g., either issuer-specified limits, or defaultlimits). Each set of risk limits may include one or more transactionaspects (e.g., “transaction amount limit”, “daily spending limit”). RBDmodule 750 cross-references each transaction aspect with the determinedtransaction risk level 850 for the subject transaction to determine anassociated threshold limit (e.g., a cell of Table 3). RBD module 750, inthe example embodiment, then identifies a reference value associatedwith each transaction aspect. The reference value is the value that RBDmodule 750 compares to the threshold value to determine whether or notthe transaction aspect has been exceeded. RBD module 750 examines eachtransaction aspect independently at step 870.

For example, presume an issuer of the subject payment card adopts Table3, as described above, as their set of risk limits, and presumetransaction risk level 850 for the subject transaction is “Good”.“Transaction amount limit” is related only to the subject transactionand, more specifically, to the amount of the subject transaction (e.g.,in U.S. dollars). As such, the reference value for the “transactionamount limit” is the payment amount identified in the transaction (e.g.,presume the subject transaction is for $44.95). RBD module 750identifies the reference value (e.g., from transaction 710 data),compares the payment amount, $44.95, to the threshold limit for the“Good” risk level, $250, and determines that the subject transaction isbelow the threshold level. As such, RBD module 750 would not recommendadditional user authentication based only on the “transaction amountlimit” transaction aspect.

Continuing the same example, presume that the subject payment card hasalready incurred $975 in purchases earlier on the day of the subjecttransaction. RBD module 750 evaluates the “daily spending limit”transaction aspect. “Daily spending limit” is related to the subjectpayment card and, more specifically, to the total amount that has beenspent using the subject transaction card on the same day, including theamount of the current transaction. As such, the reference value for the“daily spending limit” is a daily total of transaction amounts for thesubject payment card, $975, plus the current amount, $44.95, for a totalreference value of $1,019.95. RBD module 750 identifies the referencevalue (e.g., from historical data 760 and transaction 710 data),compares the reference value of $1,019.95 to the threshold limit for the“Good” risk level, $1,000, and determines that the subject transactionis above the threshold level. As such, RBD module 750 would recommendadditional user authentication based only on the “transaction amountlimit” transaction aspect.

Similarly, RBD module 750 examines each transaction aspect included inthe identified set of risk limits. In the example embodiment, if thesubject transaction exceeds any transaction aspect threshold, then RBDmodule 750 includes a recommendation for additional user authenticationin risk result 752. In other embodiments, more than one transactionaspects above threshold are required before a recommendation foradditional user authentication is provided in risk result 752.

In some embodiments, issuers may define limits based on payment cardaccount numbers. For example, in one specific embodiment, issuers maydefine a single set of risk limits (e.g., Table 3) for a specific bankidentification number (BIN) range. In some embodiments, a single issuermay have several different sets of risk limits for non-overlapping BINranges.

It should be understood that using Tables 1 and 2 for determiningsession trust level from a device score and an access method score ismerely exemplary, and other combinations of scores are possible.Further, in other embodiments, RBD module 750 generates numeric valuesfor one or more of device score, access method score, card verificationscore, session trust level, and transaction risk level include numericvalues rather than, or in addition to, the tiered levels described inthe example embodiment above.

In some embodiments, RBD module 750 may enable the “liable parties”(e.g., issuers 28 and/or merchants 24) to customize scoring for theirassociated transactions. In other words, the liable parties may providescoring rules 770 that influence one or more of device score 810, methodscore 820, verification score 840, session trust level 830, and/ortransaction risk level 850. For example, one liable party may believethat the device score is a better indicator of fraud than access methodor card verifications scores and, as such, may elect to weight thedevice score more relative to access method score and card verificationscore. In one embodiment, RBD module 750 may implement a customizedTable 1 and/or a customized Table 2 to affect such weighting. In anotherembodiment, liable parties may weight specific, more granular aspects ofeach score (i.e., weight the components of each score as to how heavilythey contribute to that score). For example, RBD module 750 may enableliable parties to weight the access method used to access a digitalwallet relative to how long a payment card has been loaded into adigital wallet. As such, RBD module 750 may provide greater granularityof control to the liable parties, thereby allowing them to influence therisk determination.

FIG. 9 is a diagram of an example payment network 900 in which atransaction processing system (TPS) 910 facilitates risk-baseddecisioning of a card-not-present (CNP) payment card transaction (the“suspect transaction” or “subject transaction”) between a suspectconsumer 902 and a merchant 24. In some embodiments, payment network 900may be similar to multi-party transaction card industry system 20 (shownin FIG. 1), suspect consumer 902 may be similar to cardholder 602 and/orsuspect consumer 702, and TPS 910 may be similar to TPS 122 (shown inFIGS. 2 and 3). In the example embodiment, suspect consumer 902 performsan online payment card transaction with merchant 24 and, during thissubject transaction, a transaction authentication request is generatedand sent to TPS 910. In some embodiments, TPS 910 is associated with aninterchange network such as network 28. In other embodiments, TPS 910 isassociated with a third-party processing service such as, for example, a3-D Secure (3DS) authentication service.

In the example embodiment, TPS 910 transmits a scoring request to arisk-based decisioning (RBD) system 920 for fraud analysis and scoring.In some embodiments, RBD system 920 is a third-party fraud screeningservice. In other embodiments, RBD system 920 is provided by network 28or issuer 30 (shown in FIG. 1). In some embodiments, RBD system 920 issimilar to RBD system 121 (shown in FIGS. 2 and 3) and/or RBD module 750(shown in FIGS. 7 and 8). In the example embodiment, the scoring requestto RBD system 920 includes infrastructure data such as one or more oftransaction data, information about a computing device used to conductthe subject transaction (“device information”, e.g., geo-location dataof the device Internet protocol (IP) address), additional payment cardinformation not included in the transaction data (“payment cardinformation”), information about a digital wallet used to conduct thesubject transaction (“digital wallet information”, e.g., whether and/orhow often this particular device has been used in conjunction with thisdigital wallet), and cart data associated with the subject transaction(“cart data”).

RBD system 920, in the example embodiment, scores the subjecttransaction for fraud using at least some of the provided data. Morespecifically, under Verified Checkout, RBD system 920 generates a riskresult 922 (e.g., a risk score) for the transaction. In someembodiments, risk result 922 is similar to risk result 752 (shown inFIGS. 7 and 8). As such, at step 924, if risk result 922 does notinclude a recommendation to perform additional authentication (e.g.,less risky transaction), such as described above with respect to FIG. 8,then no additional authentication of suspect consumer 902 is performed(e.g., no “step-up”). In other embodiments, risk result 922 may be arisk score. As such, at step 924, if the risk score satisfies a firstpre-defined threshold (i.e., the risk score indicates that thetransaction is less risky), then no additional authentication of suspectconsumer 902 is performed (e.g., no “step-up”). TPS 910 thus confirmsthat the transaction risk is acceptable (e.g., no step-up required) atstep 926, no authentication data 928 is included in the post-back tomerchant 24, and the merchant is informed and subsequently proceeds toauthorization of the payment card transaction. Further, in someembodiments, TPS 910 and/or RBD system 920 may enable merchant 24 and/orissuer 30 to customize authentication scoring as described in referenceto FIGS. 6-8.

In the example embodiment, if risk result 922 includes a recommendationfor additional authentication of suspect consumer 902, or if the riskscore satisfies a second pre-defined threshold, which may be the same asor different from the first pre-defined threshold (i.e., the risk soreindicates that the transaction is more risky), then additionalauthentication of suspect consumer 902 will be performed. Morespecifically, TPS 910 initiates (e.g., transmits) a request to anadditional authentication service 930, and the authentication service930 performs an authentication challenge 932 of suspect consumer 902. Insome embodiments under Verified Checkout, TPS 910 may include additionalextension data when initiating the request to additional authenticationservice 930, as described in reference to FIGS. 10 and 11. In theexample embodiment, additional authentication service 930 is a 3-DSecure provider that performs a step-up challenge of suspect consumer902. In some embodiments, authentication service 930 is similar toauthentication service 123 (shown in FIGS. 2 and 3). After a successfulstep-up challenge, authentication data 934 (e.g., 3DS values) ispopulated in the post-back to merchant 24, and merchant 24 proceeds toauthorization of the suspect transaction.

In some embodiments, TPS 910 offers to individual merchants 24 and/ormerchant banks 26 three options for transaction authentication 906 ofCNP payment card transactions: (1) Basic Checkout; (2) VerifiedCheckout; and (3) Advanced Checkout. Basic Checkout offers a limitedlevel of transaction authentication that does not include an option foradditional authentication challenge of suspect consumer 902 (e.g., no3DS step-up challenge), and thus no liability shift (i.e., the merchantretains liability for the subject transaction). Advanced Checkout, onthe other hand, includes liability shift from the merchant, but may alsoprompt additional authentication challenge of suspect consumer 902.Verified Checkout is a middle ground between Basic and Advanced, inwhich suspect consumer 902 is only subject to additional authenticationchallenge if the subject transaction exceeds a certain risk threshold.

In the example embodiment, TPS 910 provides merchants and/or merchantacquiring banks three different check-out choices, along with tiers ofrisk scoring options. Different merchants may desire different liabilityresponsibilities and/or different consumer experiences for theircustomers. For example, for some small merchants who conduct smallnumbers of transactions, every single transaction is important. Such amerchant may desire liability shift to issuers on most or alltransactions. On the other hand, large merchants who conduct largenumbers of transactions may accept a certain risk of fraudulenttransactions in exchange for the expected benefit of not losing theabandoned transactions. As such, TPS 910 provides merchant value in theform of enabling merchants to balance between consumer experience andliability protection. In some embodiments, merchants may select Basic,Advanced, or Verified Checkout for different types of transactions.Merchant may configure a settings profile dictating what types oftransactions are processed with which method.

In some embodiments, under Basic Checkout, TPS 910 does not provideadditional a consumer authentication challenge option, and no liabilityshift to issuer is possible (e.g., liability stays with merchant). Insuch embodiments, RBD 920 may collect data, but may not score, or mayonly partially score the subject transaction (e.g., device-data onlyscoring). In some embodiments, a flag “NOTIFY” is provided as a part ofthe subject transaction, and serves as an indicator, to TPS 910 and/orRBD 920, what check-out choice the merchant has elected for thistransaction. In some embodiments, NOTIFY prompts RBD 920 to record riskdata (e.g., what card and/or device combination has been used) forfuture use and not score or only partially score the subjecttransaction. Thus, RBD 920 may not provide risk result 922 to merchant24.

In some embodiments, under Verify Checkout, TPS 910 invokes RBD 920 tocalculate risk result 922. RBD 920 may provide risk scoring as describedabove similar to RBD 750 (shown in FIGS. 7 and 8). In some embodiments,RBD 920 may provide scoring with default scoring rules (e.g., one ormore default scoring rules stored in a memory of RBD 920), or may applyissuer- or merchant-specific settings (e.g., one or more fraud scoringconfiguration parameters received from a merchant or an issuer). If, at924, risk result 922 exceeds a pre-determined threshold, then a step-upchallenge 932 may be presented to suspect consumer 902. As such, underVerified Checkout, liability shift from merchant to issuer may notnecessarily occur.

In some embodiments, under Advanced Checkout, TPS 910 ensures liabilityshift to the issuer. TPS 910 invokes RBD 920 to score the subjecttransaction. Suspect consumer 902 may or may not be challenged 932. Ifthe issuer does not participate in scoring by RBD 920 (e.g., asexplained above in reference to FIG. 8), then step-up 924 withadditional authentication service 930 may always be performed. If theissuer does participate in scoring by RBD 920 (e.g., by providing to RBD920 one or more fraud scoring configuration parameters), or performstheir own risk-based decisioning to determine whether or not to step-up924 to challenge suspect consumer 902, then suspect consumer 902 may ormay not get challenged 932, based on the results of, for example, riskresult 922.

In some embodiments, at least one of TPS 910 and RBD 920 is configuredto store an indication of the party liable for the transaction, suchthat if a dispute arises about the transaction, the indication ofliability may be recalled. For example, under Basic Checkout, asdescribed above, the merchant may assume liability. At least one of TPS910 and RBD 920 may store an indication of merchant liability for eachtransaction. Under Advanced Checkout, as described above, liability mayshift to the issuer. At least one of TPS 910 and RBD 920 may store anindication of issuer liability for each transaction. Under VerifiedCheckout, as described above, the liability may remain with the merchantfor certain (less risky) transactions, for which an indication ofmerchant liability may be stored, and liability may shift to the issuerfor certain (riskier) transaction, for which an indication of issuerliability may be stored.

FIG. 10 is a swimlane diagram illustrating an example portion of anauthentication request process 1000 that includes providingauthentication data to an issuer during transaction authentication. Inthe example embodiment, an online transaction involving a digitalwallet, such as transaction 710 (shown in FIG. 7) involving digitalwallet 600, is processed by an interchange network such as transactionenvironment 20 (shown in FIG. 1).

During the example transaction, at step 1010, suspect consumer 702commences an online purchase with merchant 24 (e.g., selects a button onthe merchant's web site indicating that the user is ready to check out).Suspect consumer 702 selects, for example, digital wallet 600 providedby a wallet provider 1002. At step 1015, the transaction proceeds towallet provider 1002 (e.g., after suspect consumer 702 logs into digitalwallet 600). At step 1020, wallet provider 1002 notifies merchant 24 ofthe login, and may provide data associated with digital wallet 600(e.g., a selection of payment cards present available to suspectconsumer 702 through digital wallet 600). Merchant 24 (e.g., via themerchant's web site) displays data associated with digital wallet 600 tosuspect consumer 702 (e.g., confirming login to wallet, and/or paymentcard selection information). Suspect consumer 702 selects a particularpayment card (the “subject payment card”) to use with this transaction,and submits the transaction for processing.

At step 1030 a, in the example embodiment, the transaction is sent towallet provider 1002 who, at step 1035, transmits transactioninformation (e.g., payment information) and other information (e.g.,digital wallet information 730) to a merchant plug-in (MPI) system 1004.In other embodiments, such as when a digital wallet is not used, thetransaction is sent (e.g., step 1030 b) directly to MPI 1004 along withat least transaction information.

MPI 1004 initiates an authentication process associated with the subjecttransaction. More specifically, in the example embodiment, MPI 1004gathers various data associated with the transaction and initiates anauthentication transaction for authenticating suspect consumer 702. Insome embodiments, MPI 1004 is similar to transaction processing system910 (shown in FIG. 9). In other embodiments, MPI 1004 is similar to RBD750 (shown in FIGS. 7 and 8). In some embodiments, MPI 1004 is a part ofnetwork 28. In the example embodiment, MPI 1004 gathers data includingone or more of device information 720, digital wallet information 730,and payment card information 740 (as shown and described in reference toFIGS. 7 and 8). Further, MPI 1004 also identifies one or more of devicescore 810, access method score 820, card verification score 840, sessiontrust level 830, transaction risk level 850, baseline recommendation860, and/or risk result 752 (all shown and described in reference toFIGS. 7 and 8). For example, in one embodiment, MPI 1004 computes riskresult 752 similar to RBD 750.

Steps 1040, 1045, 1050, and 1055 represent an example authenticationtransaction 1042 under the 3DS protocol. In some embodiments,authentication transaction 1042 is similar to transaction authentication906 (shown in FIG. 9). In the example embodiment, MPI 1004 providesfraud-related data during a verification process to the issuing bankassociated with the subject payment card (e.g., issuer 30) and/or anaccess control server (ACS) 1006 associated with issuer 30. Morespecifically, MPI 1004 provides fraud-related data to ACS 1006 usingextension messages in the 3DS protocol within, for example, anenrollment check (VeReq, or “verification request”) message 1044. Thefraud-related data incorporated into VeReq message 1044 is described ingreater detail below.

In the example embodiment, as a part of 3DS enrollment check, MPI 1004,network 28, and ACS 1006 utilize a non-critical extension to a 3DS VeReqmessage 1044 to pass fraud-related information to issuer 30 and/or ACS1006. At step 1040, MPI 1004 generates VeReq message 1044 to includefraud-related data in an extension, and transmits VeReq message 1044 toa directory server 1008 associated with network 28. Directory server1008 identifies issuer 30 and ACS 1006 by a primary account number (PAN)of the subject payment card and transmits VeReq message 1004 to ACS1006. Issuer 30 and/or ACS 1006 extracts the fraud-related data (e.g.,the extensions) from VeReq message 1044 for consideration whendetermining how to respond (e.g., the status given in a VeRes responsemessage (not shown)).

Issuer 30, or ACS 1006 on behalf of issuer 30, may use the fraud-relateddata for many uses such as, for example, implementing their ownrisk-based decisioning system similar to RBD 750, 920. ACS 1006determines a result of the enrollment check and, at steps 1050 and 155,responds with that result to directory server 1008 and back to MPI 1004.Based on the given result, the payment card transaction may be, forexample, failed (e.g., if the subject payment card is ineligible for 3DSstep-up authentication) or authenticated (e.g., receiving anAUTHENTICATION_COMPLETE message indicates that the issuer has sufficientdata to authenticate the suspect consumer without any furtherinteraction with the cardholder) or as requiring a challenge (e.g.,receiving a CHALLENGE_REQUIRED message indicates that the issuer ACS hasdetermined that the suspect consumer has to be challenged beforeproceeding with the transaction). In the example embodiment, a VeResmessage (not shown in FIG. 10) includes an extension including an<authenticationAction> section including one of AUTHENTICATION_COMPLETEor CHALLENGE_REQUIRED that serves as a determination whether or not tofurther authenticate the suspect consumer 702 (e.g., the step-up 924conditional shown in FIG. 9).

In the example embodiment, the extension to VeReq message 1044 is anextended markup language (XML) section nested into (e.g., added into) abase VeReq message as defined by the 3DS protocol. The extension sectionis started with a “<Extension>” start-tag and ended with a“</Extension>” end-tag. For example, consider the following example:

TABLE 4 Example VeReq Message with Extensions Line# Message Text (01)<ThreeDSecure><Message id=“vDNoqT3xtC7ShMIot2Z0”><VeReq><version>1.0.2</version> <pan>521729******3800</pan><Merchant><acqBIN>123456</acqBIN> (05) <merID>123456789012</merID><name>Acme Bank Credit Card</name> <country>826</country><url>http://www.bankurl.com/</url> </Merchant> (10)<Browser><deviceCategory>0</deviceCategory></Browser><Purchase><xid>1a2b3c4d5e6f7g8h9i0j=</xid> <date>2014010122:00:00</date> <amount>&#163;1,067.78</amount><purchAmount>106778</purchAmount> (15) <currency>826</currency><exponent>2</exponent> </Purchase> <Extension id=“TrustedThirdParty”critical=“false”> <version>1.0</version> (20) <RiskDetermination><transactionID>xxyyzz</transactionID> <provider>01</provider> <scoremin=“0” max=“1000”>980</score> </RiskDetermination> (25) <Wallet><provider>Wallet Provider Co.</provider><authenticationSessionID>aslkjslk4jlks889wuxxuo</authenticationSessionID><authenticationValidationSupport>false</authenticationValidationSupport><transactionRefNumber>wrozorkl2251skjo0oiu</transactionRefNumber> (30)<userProfileID>abcxyz</userProfileID><userAuthenticationStrength>Excellent</userAuthenticationStrength><userAccountAge>565</userAccountAge> <userConfidenceScore min=“”max=“”></userConfidenceScore> <paymentCardAge></paymentCardAge> (35)<paymentCardValidationMethod></paymentCardValidationMethod><deviceConfidencelevel></deviceConfidencelevel> </Wallet> </Extension></VeReq></Message></ThreeDSecure>

The example VeReq message shown in Table 4 includes several fields thatprovide transaction data associated with the subject transaction, suchas a primary account number at line (3), merchant information at lines(4) to (9) (e.g., a merchant ID, an acquirer BIN), and purchaseinformation at lines (11) to (17) (e.g., a purchase amount and date).Further, the example VeReq message includes an extension section atlines (18) to (37). This extension section contains one or more elementsof fraud-related information.

In the example embodiment, the extension section includes one or moresub-sections, or sections within the extension section. In the exampleshown in Table 4, the extension section includes two sub-sections: a<RiskDetermination> section from lines (20) to (24) (terminated by</RiskDetermination>) and a <Wallet> section from lines (25) to (37)(terminated by </Wallet>). Each of these sections embeds informationassociated with one or more aspects of risk scoring of the subjecttransaction. Each sub-section of the extension section is referred toherein by the extension sub-section's start-tag, for convenience.Further, it should be understood that the exact sub-section tag namesused as examples herein are merely example tag names, and these tag namemay vary within the scope of this disclosure.

In the example embodiment, the <RiskDetermination> section is directedto providing an overall risk score provided by a risk-based decisioningservice such as RBD 750 or 920 (e.g., baseline recommendation 860 and/orrisk result 752, both shown in FIG. 8). In the example shown in Table 4,<RiskDetermination> includes a <transactionID> (e.g., line (21)), a<provider> (e.g., line (22)), and a <score> (e.g., line (23)).<provider> is an identifier specifying the provider of the risk score(e.g., the party associated with RBD 750 or 920). <transactionID> is aunique ID for the subject transaction that may be used to identify thisparticular transaction at a later date. <score> is a value thatrepresents the overall score assigned to this transaction (e.g., by<provider>). In this example, the <provider> has generated a score of“980” for this transaction (on a scale between “0” and “1,000”). In someembodiments, <RiskDetermination> may also include a <recommendation>sub-section. <recommendation> represents a recommended course of actionbased on <score>. In one embodiment, <recommendation> is an enumerateddata type consisting of either “Good” or “Bad”, which may be used byissuer 30 or ACS 1006 to determine whether or not to allow thetransaction to process without further authentication (e.g., without 3DSstep-up challenge 932 (shown in FIG. 9)).

In the example embodiment, the <Wallet> section is directed to providinginformation associated with a digital wallet (e.g., digital walletinformation 730 for digital wallet 600, both shown in FIG. 7). In theexample shown in Table 4, <Wallet> includes a <provider> sectionrepresenting the provider of the digital wallet (e.g., “Wallet ProviderCo.”) and, in some embodiments, may include sub-sections for theprovider's name and/or identifier. <Wallet> also includes a<authenticationSessionID> section representing a unique identifier(e.g., “aslkjslk4jlks889wuxxuo”) associated with an authenticationsession of the subject transaction with the subject digital wallet.<Wallet> further includes a <authenticationValidationSupport> sectionindicating whether validation support is included in the digital wallet.

In the example embodiment, the <Wallet> section also includes a<transactionRefNumber> section representing a unique identifier (e.g.,“wrozorkl225lskjo0oiu”) associated with the transaction and the wallet.<Wallet> also includes a <userProfileID> section representing a uniqueidentifier (e.g., “abcxyz”) associated with the user account of thewallet. <Wallet> further includes a <userAuthenticationStrength> sectionrepresenting an enumerated value indicating the login strength (e.g.,“Excellent”) associated with the suspect consumer's authentication orlogin to the subject digital wallet. In some embodiments, thisenumerated list includes “fraud”, “basic”, “good”, “excellent”, and“trusted”.

In the example embodiment, <Wallet> also includes a <userAccountAge>section representing a length of time (e.g., 565 days) the subjectdigital wallet has been active. <Wallet> further includes a<userConfidenceScore> representing a score or sub-score associated withhow the suspect consumer authenticated with the subject digital walletduring this transaction and/or past transactions.

Further, in the example embodiment, <Wallet> also includes a<paymentCardAge> section representing a length of time the subjectpayment card has been associated with the subject digital wallet.<Wallet> also includes a <paymentCardValidationMethod> section. <Wallet>also includes a <deviceConfidencelevel> section representing a score orsub-score associated with the device accessing the subject wallet duringthe subject transaction (e.g., in some embodiments, device score 810).

In some embodiments, <Wallet> may also include a <score> sectionrepresenting an overall transaction trust level score based on digitalwallet information associated with the subject digital wallet as used inthe subject transaction. For example, <score> may be an access methodscore 820 generated by RBD 750 using digital wallet information 730 asdescribed and shown in relation to FIGS. 7 and 8. In some embodiments,<score> may be provided by the digital wallet provider. In someembodiments, this score may be provided in addition to, or in lieu of,<transactionTrustLevel>. Alternatively, this “wallet score” may beprovided as a subsection of <RiskDetermination>. In other embodiments,other digital wallet information 730 may be included as sub-sections of<wallet>.

In some embodiments, the <RiskDetermination> section also includes a<deviceTrustLevel> section that represents a score associated with thesubject device used during the subject transaction. In some embodiments,the <deviceTrustLevel> includes one of an enumerated list that includes“fraud”, “basic”, “good”, “excellent”, and “trusted”. In someembodiments, the <deviceTrustLevel> is similar to device score 810(shown in FIG. 8). In some embodiments, the <deviceTrustLevel> isdetermined based at least in part on device information 720 (shown inFIGS. 7 and 8).

Further, in some embodiments, the <RiskDetermination> section alsoincludes a <sessionTrustLevel> section that represents a scoreassociated with a trustworthiness of the login session associated withthe subject payment card transaction. In some embodiments,<sessionTrustLevel> includes one of an enumerated list that includes“basic”, “good”, “excellent”, and “trusted”. In some embodiments,<sessionTrustLevel> is similar to session trust level 830 (shown in FIG.8).

FIG. 11 is an example method 1000 for risk-based analysis of a paymentcard transaction using, for example, the risk-based decisioning (RBD)system 750, 910 shown in FIGS. 7-9 in the example environment 100 shownin FIG. 1. In the example embodiment, method 1000 is performed by acomputing system such as server 112 (shown in FIG. 2), transactionprocessing system 122 (shown in FIGS. 3 and 6), RBD module 750 (shown inFIGS. 7 and 8), or RBD system 920 (shown in FIG. 9). In the exampleembodiment, method 1100 includes receiving 1102 a request forauthentication of the payment card transaction. The payment cardtransaction includes a suspect consumer presenting a payment card from adigital wallet of a privileged cardholder. Method 1100 further includesidentifying 1104 fraud feature data from the digital wallet. Method 1100also includes computing 1106 a fraud score for the payment cardtransaction based at least in part on the fraud feature data. Method1100 further includes providing 1108 the fraud score for use duringauthentication of the suspect consumer.

FIG. 12 is an example method 1200 for providing risk-based decisioningto a merchant during payment card transactions in the exampleenvironment 100 shown in FIG. 1. In the example embodiment, method 1200is performed by a computing system such as server 112 (shown in FIG. 2),transaction processing system 122 (shown in FIGS. 3 and 6), RBD module750 (shown in FIGS. 7 and 8), or RBD system 920 (shown in FIG. 9). Inthe example embodiment, method 1200 includes receiving 1202, from themerchant, transaction data associated with a payment card transaction.The payment card transaction includes a suspect consumer presenting apayment card from a digital wallet of a privileged cardholder. Method1200 further includes computing 1204 a risk score for the payment cardtransaction based at least in part on the transaction data andinfrastructure data associated with the payment card transaction. Method1200 also includes transmitting 1206 an indication of acceptable risk tothe merchant if the risk score satisfies a first pre-defined threshold.Thereby, the merchant may continue processing the payment cardtransaction without liability shifting away from the merchant. Method1200 further includes initiating 1208 an authentication challenge of thesuspect consumer if the risk score satisfies a second pre-definedthreshold. Thereby, liability may shift away from the merchant.

FIG. 13 is an example method 1300 for providing fraud data within anauthentication system including an authentication protocol. In theexample embodiment, method 1300 is performed by a computing system suchas server 112 (shown in FIG. 2), transaction processing system 122(shown in FIGS. 3 and 6), RBD module 750 (shown in FIGS. 7 and 8), orRBD system 920 (shown in FIG. 9). In the example embodiment, method 1300includes identifying 1302 fraud feature data associated with a paymentcard transaction. The payment card transaction includes a suspectconsumer presenting a payment card from a digital wallet of a privilegedcardholder. Method 1300 also includes computing 1304 a first risk scorefor the payment card transaction based at least in part on the fraudfeature data. Method 1300 further includes generating 1306 a message inthe authentication protocol, the message including at least oneextension field. The first risk score is included within the at leastone extension field. Method 1300 also includes transmitting 1308 themessage with the first risk score included within the at least oneextension field to a party associated with the payment card transactionfor use during authentication of the payment card transaction.

FIG. 14 shows an example configuration 1400 of a database 1420 within acomputing device 1410, along with other related computing components,that may be used to analyze of a payment card transaction for risk, toprovide risk-based decisioning to a merchant during payment cardtransactions, and/or to provide fraud data within an authenticationsystem including an authentication protocol. In some embodiments,computing device 1410 is similar to server 112 (shown in FIG. 2),transaction processing system 122 (shown in FIGS. 3 and 6), RBD module750 (shown in FIGS. 7 and 8), RBD system 920 (shown in FIG. 9), and/orserver system 301 (shown in FIG. 5). Database 1420 is coupled to severalseparate components within computing device 1410, which perform specifictasks.

In the example embodiment, database 1420 includes digital wallet data1422, transaction data 1424, and device and payment card data 1426. Insome embodiments, database 1420 is similar to database 120 (shown inFIG. 2). Digital wallet data 1422 includes information associated with acardholder's digital wallet, such as digital wallet 600 (shown in FIG.6). Transaction data 1424 includes information associated with paymentcard transactions. Device and payment card data 1426 includes dataassociated with device(s) used to conduct payment card transactions andpayment card data used in those transactions.

Computing device 1410 includes the database 1420, as well as datastorage devices 1430. Computing device 1410 also includes a fraudscoring component 1440 for computing fraud scores (e.g., risk result752). Computing device 1410 also includes an authentication component1450 (e.g., authentication service 930, shown in FIG. 9) for performingaspects of cardholder authentication. A transaction component 1460 isalso included for performing aspects of payment card transactionprocessing. A communications component 1470 is also included forcommunicating data between components associated with the payment cardtransaction process. A processing component 1480 assists with executionof computer-executable instructions associated with the system.

As will be appreciated based on the foregoing specification, theabove-described embodiments of the disclosure may be implemented usingcomputer programming or engineering techniques including computersoftware, firmware, hardware or any combination or subset thereof,wherein the technical effect is a flexible system for various aspects offraud analysis of payment card transactions. Any such resulting program,having computer-readable code means, may be embodied or provided withinone or more computer-readable media, thereby making a computer programproduct, i.e., an article of manufacture, according to the discussedembodiments of the disclosure. The computer-readable media may be, forexample, but is not limited to, a fixed (hard) drive, diskette, opticaldisk, magnetic tape, semiconductor memory such as read-only memory(ROM), and/or any transmitting/receiving medium such as the Internet orother communication network or link. The article of manufacturecontaining the computer code may be made and/or used by executing thecode directly from one medium, by copying the code from one medium toanother medium, or by transmitting the code over a network.

These computer programs (also known as programs, software, softwareapplications, “apps”, or code) include machine instructions for aprogrammable processor, and can be implemented in a high-levelprocedural and/or object-oriented programming language, and/or inassembly/machine language. As used herein, the terms “machine-readablemedium” “computer-readable medium” refers to any computer programproduct, apparatus and/or device (e.g., magnetic discs, optical disks,memory, Programmable Logic Devices (PLDs)) used to provide machineinstructions and/or data to a programmable processor, including amachine-readable medium that receives machine instructions as amachine-readable signal. The “machine-readable medium” and“computer-readable medium,” however, do not include transitory signals.The term “machine-readable signal” refers to any signal used to providemachine instructions and/or data to a programmable processor.

This written description uses examples to disclose the disclosure,including the best mode, and also to enable any person skilled in theart to practice the disclosure, including making and using any devicesor systems and performing any incorporated methods. The patentable scopeof the disclosure is defined by the claims, and may include otherexamples that occur to those skilled in the art. Such other examples areintended to be within the scope of the claims if they have structuralelements that do not differ from the literal language of the claims, orif they include equivalent structural elements with insubstantialdifferences from the literal languages of the claims.

1-21. (canceled)
 22. A computing device for providing fraud indicatordata within an authentication system including an authenticationprotocol, said computing device comprising a processor communicativelycoupled to a memory, said processor programmed to: receive, from amerchant computing device, transaction information associated with apayment card transaction in the authentication protocol prior toauthorization of the payment card transaction, the payment cardtransaction initiated by a suspect consumer using a payment card from adigital wallet, wherein the transaction information includes digitalwallet identifying data captured by the merchant computing device duringinitiation of the payment card transaction; parse fraud indicator datafrom the transaction information, wherein the fraud indicator dataincludes digital wallet authentication data from the digital walletidentifying data, the digital wallet authentication data including anauthentication history of previous payment card transactions initiatedusing the payment card while the payment card has been in the digitalwallet; compute a first risk score for the payment card transactionbased at least in part on the fraud indicator data; generate anauthentication recommendation based at least in part on the first riskscore, the authentication recommendation indicating whether to initiatefurther authentication of the suspect consumer; generate an issuerauthentication recommendation message in the authentication protocol,the issuer authentication recommendation message including a pluralityof extension fields, wherein the first risk score is included within afirst of the plurality of extension fields, a first element of thedigital wallet authentication data is included within a second of theplurality of extension fields, and the authentication recommendation isincluded within a third of the plurality of extension fields, andwherein the plurality of extension fields are formatted as an ExtensibleMarkup Language (XML) extension section of the issuer authenticationrecommendation message in the authentication protocol; identify, fromthe transaction information, an issuer computing device associated withthe payment card from the digital wallet that was used to initiate thepayment card transaction; transmit the issuer authenticationrecommendation message with the XML extension section to the issuercomputing device for use by the issuer computing device in determiningwhether to proceed with further authentication of the suspect consumer;receive, from the issuer computing device, an authentication resultmessage including a determination made by the issuer computing device toauthenticate the suspect consumer as the legitimate cardholder withoutany further interactions with the suspect consumer, including step-upchallenge messaging, based on the issuer authentication recommendationmessage; and transmit a message to the merchant computing deviceindicating authentication of the suspect consumer is successful, whereinreceipt of the message causes the merchant computing device to proceedwith authorization of the payment card transaction without initiatingthe step-up challenge, thereby reducing step-up challenge messaging. 23.The computing device of claim 22, wherein the digital walletauthentication data further includes a loading history of the paymentcard, indicating a process by which the payment card was previouslyloaded into the digital wallet, including at least one of a method ofloading the payment card into the digital wallet and a date of theloading.
 24. The computing device of claim 22, said processor furtherprogrammed to compute the first risk score based at least in part ondevice data associated with a computing device used by the suspectconsumer with the digital wallet to initiate the payment cardtransaction.
 25. The computing device of claim 24, wherein at least afirst element of the device data is included within a fourth of theplurality of extension fields.
 26. The computing device of claim 22,wherein the digital wallet authentication data further includes anauthentication history of authenticating the suspect consumer into thedigital wallet prior to the initiation of the payment card transaction.27. The computing device of claim 22, wherein the transactioninformation includes a primary account number (PAN) of the payment card,and wherein the computing device identifies the issuer computing devicebased at least in part on the PAN.
 28. The computing device of claim 22,wherein said processor is further programmed to: receive, from theissuer computing device, the authentication result message including thedetermination made by the issuer computing device to proceed with thefurther authentication, based on the issuer authenticationrecommendation message; and initiate an authentication challenge of thesuspect consumer including transmitting a challenge request message toan access control server (ACS) computing device, wherein receipt of thechallenge request message causes the ACS computing device to transmit astep-up challenge to a user computing device for authentication of thesuspect consumer.
 29. A computer-based method for providing fraudindicator data within an authentication system including anauthentication protocol, the method implemented using a computer deviceincluding a processor and a memory, said method comprising: receiving,from a merchant computing device, transaction information associatedwith a payment card transaction in the authentication protocol prior toauthorization of the payment card transaction, the payment cardtransaction initiated by a suspect consumer using a payment card from adigital wallet, wherein the transaction information includes digitalwallet identifying data captured by the merchant computing device duringinitiation of the payment card transaction; parsing fraud indicator datafrom the transaction information, wherein the fraud indicator dataincludes digital wallet authentication data from the digital walletidentifying data, the digital wallet authentication data including anauthentication history of previous payment card transactions initiatedusing the payment card while the payment card has been in the digitalwallet; computing a first risk score for the payment card transactionbased at least in part on the fraud indicator data; generating anauthentication recommendation based at least in part on the first riskscore, the authentication recommendation indicating whether to initiatefurther authentication of the suspect consumer; generating an issuerauthentication recommendation message in the authentication protocol,the issuer authentication recommendation message including a pluralityof extension fields, wherein the first risk score is included within afirst of the plurality of extension fields, a first element of thedigital wallet authentication data is included within a second of theplurality of extension fields, and the authentication recommendation isincluded within a third of the plurality of extension fields, andwherein the plurality of extension fields are formatted as an ExtensibleMarkup Language (XML) extension section of the issuer authenticationrecommendation message in the authentication protocol; identifying, fromthe transaction information, an issuer computing device associated withthe payment card from the digital wallet that was used to initiate thepayment card transaction; transmitting the issuer authenticationrecommendation message with the XML extension section to the issuercomputing device for use by the issuer computing device in determiningwhether to proceed with further authentication of the suspect consumer;receiving, from the issuer computing device, an authentication resultmessage including a determination made by the issuer computing device toauthenticate the suspect consumer as the legitimate cardholder withoutany further interactions with the suspect consumer, including step-upchallenge messaging, based on the issuer authentication recommendationmessage; and transmitting a message to the merchant computing deviceindicating authentication of the suspect consumer is successful, whereinreceipt of the message causes the merchant computing device to proceedwith authorization of the payment card transaction without initiatingthe step-up challenge, thereby reducing step-up challenge messaging. 30.The method of claim 29, wherein the digital wallet authentication datafurther includes a loading history of the payment card, indicating aprocess by which the payment card was previously loaded into the digitalwallet, including at least one of a method of loading the payment cardinto the digital wallet and a date of the loading.
 31. The method ofclaim 29, wherein computing a first risk score further comprisescomputing the first risk score based at least in part on device dataassociated with a computing device used by the suspect consumer with thedigital wallet to initiate the payment card transaction.
 32. The methodof claim 31, wherein at least a first element of the device data isincluded within a fourth of the plurality of extension fields.
 33. Themethod of claim 29, wherein the digital wallet authentication datafurther includes an authentication history of authenticating the suspectconsumer into the digital wallet prior to the initiation of the paymentcard transaction.
 34. The method of claim 29, wherein the transactioninformation includes a primary account number (PAN) of the payment card,and wherein the computing device identifies the issuer computing devicebased at least in part on the PAN.
 35. The method of claim 29, furthercomprising: receiving, from the issuer computing device, theauthentication result message including the determination made by theissuer computing device to proceed with the further authentication,based on the issuer authentication recommendation message; andinitiating an authentication challenge of the suspect consumer includingtransmitting a challenge request message to an access control server(ACS) computing device, wherein receipt of the challenge request messagecauses the ACS computing device to transmit a step-up challenge to auser computing device for authentication of the suspect consumer.
 36. Atleast one non-transitory computer-readable storage media havingcomputer-executable instructions embodied thereon, wherein when executedby at least one processor, the computer-executable instructions causethe processor to: receive, from a merchant computing device, transactioninformation associated with a payment card transaction in theauthentication protocol prior to authorization of the payment cardtransaction, the payment card transaction initiated by a suspectconsumer using a payment card from a digital wallet, wherein thetransaction information includes digital wallet identifying datacaptured by the merchant computing device during initiation of thepayment card transaction; parse fraud indicator data from thetransaction information, wherein the fraud indicator data includesdigital wallet authentication data from the digital wallet identifyingdata, the digital wallet authentication data including an authenticationhistory of previous payment card transactions initiated using thepayment card while the payment card has been in the digital wallet;compute a first risk score for the payment card transaction based atleast in part on the fraud indicator data; generate an authenticationrecommendation based at least in part on the first risk score, theauthentication recommendation indicating whether to initiate furtherauthentication of the suspect consumer; generate an issuerauthentication recommendation message in the authentication protocol,the issuer authentication recommendation message including a pluralityof extension fields, wherein the first risk score is included within afirst of the plurality of extension fields, a first element of thedigital wallet authentication data is included within a second of theplurality of extension fields, and the authentication recommendation isincluded within a third of the plurality of extension fields, andwherein the plurality of extension fields are formatted as an ExtensibleMarkup Language (XML) extension section of the issuer authenticationrecommendation message in the authentication protocol; identify, fromthe transaction information, an issuer computing device associated withthe payment card from the digital wallet that was used to initiate thepayment card transaction; transmit the issuer authenticationrecommendation message with the XML extension section to the issuercomputing device for use by the issuer computing device in determiningwhether to proceed with further authentication of the suspect consumer;receive, from the issuer computing device, an authentication resultmessage including a determination made by the issuer computing device toauthenticate the suspect consumer as the legitimate cardholder withoutany further interactions with the suspect consumer, including step-upchallenge messaging, based on the issuer authentication recommendationmessage; and transmit a message to the merchant computing deviceindicating authentication of the suspect consumer is successful, whereinreceipt of the message causes the merchant computing device to proceedwith authorization of the payment card transaction without initiatingthe step-up challenge, thereby reducing step-up challenge messaging. 37.The computer-readable storage media of claim 36, wherein the digitalwallet authentication data further includes a loading history of thepayment card, indicating a process by which the payment card waspreviously loaded into the digital wallet, including at least one of amethod of loading the payment card into the digital wallet and a date ofthe loading.
 38. The computer-readable storage media of claim 36,wherein the computer-executable instructions further cause the processorto compute the first risk score based at least in part on device dataassociated with a computing device used by the suspect consumer with thedigital wallet to initiate the payment card transaction.
 39. Thecomputer-readable storage media of claim 38, wherein at least a firstelement of the device data is included within a fourth of the pluralityof extension fields.
 40. The computer-readable storage media of claim36, wherein the digital wallet authentication data further includes anauthentication history of authenticating the suspect consumer into thedigital wallet prior to the initiation of the payment card transaction.41. The computer-readable storage media of claim 36, wherein thetransaction information includes a primary account number (PAN) of thepayment card, and wherein the computing device identifies the issuercomputing device based at least in part on the PAN.